[БЕЗ_ЗВУКА] В предыдущем видео мы с вами внедрили шаблон RunTest, который позволил нам только в одном месте указывать блок try catch и передавать в него произвольный тест. При этом мы забыли добавить в него одну весьма удобную вещь, давайте уже это сделаем. Вот, смотрите. Наши юнит-тесты в конце явно выводят в cout сообщение OK о том, что они выполнились и не нашли никаких ошибок. Вот у нас это в TestAreSynonyms, в TestCount этот OK выводится и здесь. Это, соответственно, не очень удобно требовать, чтобы в конце каждого юнит-теста был явный вывод OK в cout. Потому что когда мы пишем новый тест, мы можем это забыть сделать, и, соответственно, у нас в консоль ничего не будет выводиться, мы будем думать, что наш тест не запускается, не выполняется, хотя на самом деле он просто ничего не выводит. И хочется как-то избавить пользователя нашего фреймворка от этого недостатка. Хочется, чтобы этот фреймворк делал все самостоятельно. И мы можем это сделать. Давайте посмотрим на RunTest. Мы же принимаем в него уже test_name. Мы уже принимаем в него имя теста и используем его для вывода сообщения fail. Давайте это же имя использовать для вывода OK. Поступим таким образом: удалим явный вывод сообщения OK из юнит-теста. Удалили. И вот здесь вот, внутри RunTest, напишем: cout << test_name << " OK" << endl; (перевод строки) Скомпилируем программу. Отлично, она компилируется. И давайте запустим. Запустили. Видим, что у нас все юнит-тесты отработали, не нашли ошибок и все вывели OK. При этом мы удалили явные выводы из самих тестов, но тем не менее у нас все работает так же, как и работало. Соответственно, теперь, когда мы будем добавлять новый юнит-тест, нам не надо помнить о том, что в конце надо вывести OK. Отлично, мы сделали наш фреймворк еще лучше, еще удобнее. Теперь давайте обратим внимание еще на такой момент. До этого момента основная программа решения задачи «Синонимы»... Я напомню, что мы работаем над юнит-тестами для решения задачи «Синонимы», потому что мы достаточно много уже времени уделили фреймворку, и кто-то из слушателей мог забыть, что мы, вообще говоря, работаем с задачей «Синонимы» из курса «Белый пояс по C++». Так вот, решение задачи «Синонимы» у нас все это время было закомментировано, и это не очень хорошо, потому что мы вносим какие-то изменения в наш код, а основная программа закомментирована, соответственно, что-то уже могло перестать компилироваться, а мы об этом не знаем. Поэтому давайте мы эту программу раскомментируем, скомпилируем и запустим. У нас выполнились юнит-тесты. Вот эти вот. Но обратите внимание на такую важную деталь — вот на вот этот красный квадрат. Он говорит о том, что наша программа продолжает выполняться, продолжает работать. Что неудивительно — мы выполнили наши тесты, а теперь перешли просто к следующей команде, вот к этому вводу из консоли. Мы можем ввести количество запросов (q — это количество запросов в нашей задаче «Синонимы») и ввести какой-то запрос, например COUNT a, попросить программу посчитать, сколько у нас на данный момент синонимов для строчки a, получить вывод 0. И смотрите, какую мы получили проблему: у нас юнит-тесты выполнились, вывели стандартный вывод OK, а потом выполнилось решение нашей задачи и тоже вывело стандартный вывод 0. Вот он. Eclipse черным цветом подкрашивает в консоли стандартный вывод. Здесь вы видите, что стандартный ввод покрашен в зеленый. И на самом деле это проблема, потому что когда вы отправляете свое решение в тестирующую систему, вы можете забыть закомментировать запуск тестов, и вы не пройдете даже, наверное, самый первый тест в решении, самый первый тест в задаче, и будете думать, что ваше решение неправильное, хотя на самом деле вы просто забыли закомментировать запуск тестов, и поэтому ваша программа не принимается тестирующей системой. И эту проблему тоже хочется обойти, потому что так неудобно. И обойти ее достаточно просто. Вот у нас есть проблема, что вывод OK в стандартный вывод смешивается с решением. Давайте, пусть юнит-тесты выводят не в стандартный вывод, а в стандартный поток ошибок. Мы до этого ни разу не упоминали его в нашем курсе, но на самом деле в этом нет ничего сложного. Давайте вернемся в Eclipse, и вот здесь, внутри функции RunTest, просто заменим cout на cerr. Всё. Мы только что научили наш тестовый фреймворк выводить не в стандартный вывод, а в стандартный поток ошибок. Компилируем нашу программу. Она компилируется. Запускаем ее и видим, что вывод тестов стал красным. Это такой способ Eclipse'а показать нам, что вывод произошел в стандартный поток ошибок, а не в стандартный вывод. Мы снова можем ввести здесь запрос и получить вывод. Вот смотрите, теперь явно видно: красным Eclipse покрасил стандартный поток ошибок, зеленым — это ввод, а черный — это стандартный вывод. Теперь, если вы забудете закомментировать тесты при отправки решения в систему, ничего страшного — они у вас выполнятся, выведут что-то в стандартный вывод, но потом выполнится решение, тесты выведут в поток ошибок, потом выполнится решение, выведет все в стандартный вывод, и, если ваше решение правильное, оно все равно будет принято тестирующей системой. Так, конечно же, нашим фреймворком будет удобно пользоваться. И я хочу подметить еще одну очень приятную деталь. Смотрите, у нас уже появляются признаки такого хорошего дизайна. Мы всего лишь в одном месте внутри функции RunTest (ну, формально в двух местах, но внутри одной маленькой функции) сделали какое-то изменение, и весь наш фреймворк получил новое свойство. Он стал выводить в другой поток вывода. Нам не пришлось ходить по всем тестам и во всех них что-то менять. Это очень хорошо, очень удобно. Мы с вами на самом деле всего лишь в шаге от того, чтобы закончить улучшать наш юнит-тест фреймворк и получить готовый к использованию программный компонент. И этот шаг мы с вами сделаем в следующем видео.
