[БЕЗ_ЗВУКА] В
предыдущем видео мы с вами внедрили шаблон 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 (ну, формально в двух местах,
но внутри одной маленькой функции) сделали какое-то изменение,
и весь наш фреймворк получил новое свойство.
Он стал выводить в другой поток вывода.
Нам не пришлось ходить по всем тестам и во всех них что-то менять.
Это очень хорошо, очень удобно.
Мы с вами на самом деле всего лишь в шаге от того, чтобы закончить улучшать
наш юнит-тест фреймворк и получить готовый к использованию программный компонент.
И этот шаг мы с вами сделаем в следующем видео.
Лежанкин Иван Андреевич
Парамонов Евгений Анатольевич
Полднев Антон Вячеславович
Шишков Илья Ивановичкандидат технических наук
