Этот курс является продолжением курса "Основы разработки на C++: белый пояс". В нём преподаватели продолжают знакомить вас с возможностями языка C++. В курсе рассмотрены: - целочисленные типы языка C++ - пары и кортежи - шаблоны функций - наследование и полиморфизм - итераторы и стандартные алгоритмы - распределение кода по нескольким файлам Кроме того, в курсе рассмотрено использование юнит-тестов для отладки программ и обеспечения надёжности кода, а также продемонстрировано, как, пользуясь знаниями только "Белого" и "Жёлтого" поясов, разработать свой собственный unit test framework. Так же, как и в "Белом поясе", в конце курса вас ждёт финальный проект. В "Белом поясе" надо было самостоятельно реализовать простое хранилище данных с возможностью добавления, удаления и поиска. В "Жёлтом поясе" это хранилище надо будет усовершенствовать, добавив поддержку более сложных запросов. Курс разработан ведущими специалистами Яндекса и преподавателями Школы анализа данных. За их плечами – годы разработки сервисов поиска, рекламы и инфраструктуры. Кроме того в подготовке заданий участвовали сотрудники Яндекса и студенты Школы анализа данных: - Александр Гришин - Алексей Аверченко - Максим Филипов - Даниил Петров - Евгений Шавлюгин - Владислав Виноградов - Алексей Боголюбский - Дмитрий Кузьмичёв - Иван Качалкин - Андрей Полушин - Андрей Корнеев - Константин Меренков
Улучшаем assert
Loading...
Из курса от партнера Moscow Institute of Physics and Technology
Основы разработки на C++: жёлтый пояс
95 оценки
Moscow Institute of Physics and Technology
95 оценки
Курс 2 из 5 — Specialization Искусство разработки на современном C++
Из урока
Тестирование и отладка
Эта неделя посвящена использованию юнит-тестов для тестирования и отладки программ. На примере мы продемонстрируем, как юнит-тесты помогают в поиске и устранении ошибок, а также что нужно делать, чтобы покрыть свой код юнит-тестами. Затем с помощью накопленных на данный момент знаний мы разработаем свой собственный фреймворк для создания юнит-тестов, которым вы сможете пользоваться в своих программах.
Познакомьтесь с преподавателями
Лежанкин Иван Андреевич
Яндекс
Парамонов Евгений Анатольевич
Яндекс
Полднев Антон Вячеславович
Яндекс
Шишков Илья Ивановичкандидат технических наук
Яндекс
[БЕЗ_ЗВУКА] Итак,
начнем последовательно улучшать наш фреймворк для создания юнит-тестов.
Первый недостаток, с которым мы начнем бороться, заключается в том,
что когда срабатывает функция assert,
то мы в консоли не видим, чему равен каждый из операндов.
Мы постараемся что-то такое сделать с нашим кодом, чтобы он работал как раньше,
но при этом, если мы в assert сравниваем между собой два аргумента,
то в консоли было видно, чему равен каждый из них.
Для начала давайте поймем, что же мы хотим.
Хотим мы следующее.
Вот у меня есть пример,
где в переменную x записывается результат сложения 2 и 2.
Мы сделаем assert, что x должен быть равен 4.
Что бы мы хотели?
Мы бы хотели, что если этот assert сработал,
то в консоли мы бы увидели вот такое сообщение.
Например, x у нас оказался не 4, а 5,
тогда мы в консоли видим сообщение Assertion failed,
то есть assert сработал, и мы видим, что x оказался равен 5.
Соответственно, мы, сразу видя, чему оказался равен x,
можем построить какую-то гипотезу, из-за чего у нас не работает функция Add.
Может быть, мы где-то случайно добавили +1.
Кроме того, мы хотим, чтобы этот вывод
в консоль работал для всех типов, а не только для целых чисел.
Посмотрим второй пример.
У нас есть вектор sorted, которому мы присваиваем результат функции Sort,
передавая туда последовательность 1, 4, 3.
И мы пишем assert, что sorted должен оказаться равен вектору {1, 3, 4},
то есть он должен отсортироваться.
Если этот assert сработает, то мы хотим в консоли увидеть вот такое сообщение.
В правой части у нас [1, 3, 4], это то, что мы ожидали.
А слева мы сразу видим,
что на самом деле после фукнции Sort вектор оказался равен [1, 4, 3].
Ровно таким, который мы передали в функцию Sort.
Значит, сразу мы можем сделать гипотезу, что, возможно,
функцию Sort просто забыли реализовать, она пустая и ничего не делает.
Или там есть какие-то странные условия,
которые приводят к тому, что последовательность не сортируется.
То есть тот факт, что мы выводим что-то в консоль при срабатывании assert,
он нам помогает отладить программу, он нам помогает догадаться,
где же на самом деле ошибка.
Хорошо.
Давайте теперь подумаем, а как мы можем этого добиться.
Смотрите, мы хотим написать какую-то функцию,
которая принимает два значения произвольного типа, сравнивает
их между собой и как-то реагирует на то, что они оказались не равны.
Мы с вами уже знаем средство языка C++,
которое позволяет в функцию принимать аргументы произвольных типов.
Это шаблоны функций.
Давайте этим воспользуемся.
Давайте напишем шаблон AssertEqual, который будет
принимать два аргумента произвольного типа и сравнивать их между собой.
Давайте это сделаем.
Переключимся в Eclipse и вот здесь сразу перед первым тестом напишем шаблон.
Пишем template <class T, class U>,
void AssertEqual
(const T& t,
const U& u).
Проверим, если t
!= u, то что надо сделать?
Если значения оказались не равны, нам нужно как-то отреагировать на это,
как-то сделать так, чтобы мы узнали, что вот этот assert не сработал.
Давайте для этого бросим исключения.
Давайте тогда подключим
exception и здесь
сделаем throw runtime_error.
И сюда, в конструктор runtime_error мы хотим передать сообщение,
в которое мы хотим пометить значение в данном случае переменных t и u.
Как это сделать?
Давайте сформируем строчку, которая это делает.
Для этого мы подключим строковые
потоки, объявим переменную
ostringstream и запишем в нее то сообщение,
которое мы хотели: Assertion failed: "
<< t
не равно u.
И передадим
в конструктор runtime_error то сообщение, которое у нас получилось.
Давайте скомпилируем то, что у нас пока есть.
Отлично, оно компилируется.
У вас мог возникнуть вопрос, а почему я здесь для двух
аргументов использую разные типы: типы t и u.
Вроде как мы же сравниваем их между собой, и логично было бы,
чтобы они были одного типа.
На самом деле, так шаблон AssertEqual более удобен в использовании,
особенно когда дело доходит до целочисленных типов.
Потому что мы с вами уже знаем, что в C++ много различных
целочисленных типов, и вот для того, чтобы сравнивать,
например, int и int64_t, которые являются разными типами,
удобно передавать их с помощью разных шаблонных аргументов,
и мы посмотрим, как мы этим будем пользоваться, совсем скоро.
Давайте этот наш шаблон AssertEqual встроим в один из тестов.
И начнем мы с теста TestCount,
который проверяет, что функция GetSynonymCount,
возвращающая количество синонимов для данного слова, работает правильно.
Что мы сделаем?
Мы заменим вызов assert на наш AssertEqual,
только внутри этой функции.
И так как у нас AssertEqual
принимает два параметра, то первым параметром является
результат вызова GetSynonymCount, а вторым то число, которое мы ожидаем.
Скомпилируем наш код.
Мы с вами видим, что у нас есть
Warning, который
[БЕЗ_ЗВУКА] нам
говорит о сравнении между знаковым и беззнаковым целыми числами.
Если мы два раза по нему нажмем, то мы попадем внутрь нашего AssertEqual.
А вот здесь, если мы нажмем ниже, то мы видим,
что это происходит при вызове AssertEqual.
В чем тут дело?
Как раз в том, что мы передаем это значение и вот
этот нолик через разные типы, и компилятор понимает,
что тип T — это тип функции GetSynonymCount,
вот она у нас, это size_t, это беззнаковый тип.
А нолик, который мы там передаем,
вот этот вот, он, как мы с вами уже знаем, имеет тип int,
это тип всех числовых констант в C++ по умолчанию.
Поэтому у нас получается сравнение size_t с int, и компилятор ругается.
Как нам этого избежать, мы уже знаем.
Мы здесь просто напишем u и сделаем тем самым константы беззнаковыми.
Снова скомпилируем наш код.
Отлично, он компилируется.
Теперь мы поступим следующим образом.
У нас с вами в этом решении допущен баг,
который мы с вами уже исправляли несколько видео назад.
Мы его исправим еще раз, чтобы не стрелял тест на функцию AddSynonyms.
Выполним наш код.
Отлично, он выполнился.
Мы видим, что все юнит-тесты успешно отработали.
Прекрасно.
Но мы на самом деле ведь вот этот AssertEqual писали не на случай,
когда все тесты успешно работают, а когда тесты стреляют.
Давайте мы с вами осознанно допустим ошибку в GetSynonymCount и убедимся,
что AssertEqual действительно выводит в консоль аргументы, когда он срабатывает.
Запустим наш код, вот у нас явно выстрелил какой-то тест.
Смотрим в консоль, и мы видим сообщение Assertion failed: 1 != 0.
При этом вы видите,
что у нас пропала та удобная вещь, которая была в оригинальной функции Assert.
Мы не видим, какой именно assert сработал.
Мы сейчас эту проблему решим достаточно быстро.
Пока же мы видим, что мы действительно выводим в консоль значения аргументов,
которые были переданы в функцию AssertEqual.
Вот здесь мы осознанно
прибавили к результату 1, поэтому у нас появилась 1, хотя мы ожидали 0.
Хорошо.
Давайте вернем в AssertEqual то преимущество, которое было
в функции Assert, пусть она нам тоже будет говорить, какой именно assert сработал.
Поступим мы здесь таким образом.
Мы в AssertEqual будем передавать строчку
hint.
Эта строчка будет выводиться в конце сообщения
теста.
Hint: "<<hint.
Чтобы в экран влезало, я это отформатирую.
Тогда мы идем в функцию
TestCount и вот здесь
вот передаем уникальную строчку, которая нам позволит
однозначно идентифицировать тот assert, который сработал.
Допустим, здесь мы напишем count for
empty и здесь тоже укажем
какие-то уникальные строчки.
[БЕЗ_ЗВУКА] Компилируем то,
что у нас получилось.
Запускаем, видим, как у нас сработал assert.
Мы видим, что он сработал и вывел в консоль count for empty.
Теперь мы можем взять эту строчку и поискать
ее в исходниках.
И понять, какой именно assert у нас сработал.
Конечно, это не настолько удобно, как было в оригинальном Asssert.
Там не надо было ничего в него добавлять, чтобы он нам сказал,
в какой именно строчке сработала проверка.
На самом деле, нам на данный момент не хватает знаний C++,
чтобы повторить эту функциональность.
Поэтому мы воспользуемся теми знаниями, которые у нас уже есть, и вот таким,
пусть не самым элегантным и не самым удобным образом,
но все-таки мы решим проблему и научим наши assert'ы сообщать,
в каком именно месте сработала проверка.
Прекрасно.
Мы в этом видео смогли — давайте я сейчас его открою — написать
шаблонную функцию AssertEqual, которая позволяет увидеть в консоли
значения аргументов при срабатывании соответствующей проверки.
В следующих видео мы внедрим этот шаблон во все наши тесты,
которые есть в нашей программе.
Ознакомьтесь с нашим каталогом
Присоединяйтесь бесплатно и получайте персонализированные рекомендации, обновления и предложения.
Coursera делает лучшее в мире образование доступным каждому, предлагая онлайн-курсы от ведущих университетов и организаций.
© Coursera Inc., 2018 Все права защищены.
