Разработка через тестирование (TDD) на C++ с использованием фреймворка Google Test

Привет!

Надеюсь, что моя видео-инструкция кому-то пригодится: ссылка

Буду рад почитать любые замечания: что хорошо, что можно улучшить и т.д.

С уважением

1

8Observer8, Приветствую, сам в данный момент занимаюсь изучением разработки через тестирование, посмотрел Вашу запись, вот несколько замечаний и предложений:
Во-первых, замечательно, что в принципе есть люди, готовые тратить своё время, создавая обучающие видео подобного рода, но как и в любом деле есть куда стремиться, итак:
1) По картинке - имхо можно было изменить захват таким образом, чтобы не оставались 2 черные полосы по бокам экрана, а разрешение можно было бы довести до 720 p
2) Звук в целом не плохой, хотя в некоторые моменты кажется, что Вы находитесь слишком близко к микрофону. Стоит избавиться от попыток заполнения пауз звуками вроде "эээ".
3) По логике - возможно стоило разделить видео на несколько самостоятельных частей - скажем, большую часть видео обсуждается не TDD, и не gtest, а просто набор манипуляций, которые нужно выполнить, чтобы с нуля настроить проект с помощью qmake в среде qtcreator.
4) По коду:
а) я бы изменил название checkIp, на более выразительное, скажем IsIpHasValidFormat, или более короткое IsIpValid. Потому-что вы пишите checkIp, а при этом вслух, на русском языке проговариваете настоящее название этого метода - что он будет делать. Кроме того, в продакшн коде, скорее всего будут условные выражение, и на мой взгляд запись:
- будет намного яснее говорить о том, что происходит, нежели
- какой такой чек? мы пытаемся проверить доступность ip адреса, или мы проверяем его валидность, или мы делаем что-то еще?
б) Вы используете названия actual, expected - на мой взгляд это, во-первых, говорит о деталях реализации (вот мы пошли тестить нашу приблуду в тестах, и там есть такие понятия - как экспектед и экшуал валью - и вот мы теперь так же назвали переменные), кроме того, если посмотреть на вывод gtest-а это вызывает непонимание:
На мой взгляд можно было назвать переменную actual как - is_ip_has_valid_format, а переменную expected - valid_ip - в случае true,
тогда вывод выглядел бы как:
Тогда хотя бы из теста можно понять, что функция тестировала - валидность ip и на самом деле ожидала результат валидного ip.
в) Вы не стали давать осмысленные названия тестам, а просто назвали их test001-008. Я считаю, если мы говорим о TDD, нужно было, либо обосновать такое поведение ( типа сначала мы не знаем толком, что тестируем, поэтому я просто назову это тестом, но потом, когда тест написан, я дам тесту корректное название) либо давать название сразу. Ибо если пошедший по Вашим стопам человек, научится писать тесты в таком стиле, получит базу из тысячи тестов, и по выводу gtest-a увидит, что имя теста test420 - он будет просто обречен идти и смотреть в код, чтобы вообще понять, а что он сломал. Если же тест бы назывался в виде (IsIpHasValidFormat, ReturnsTrueForLocalHostIp) - то уже из заголовка можно понять и что ожидается, и что подается на вход.
д) Вы зачем-то сразу накопипастили множество тестов, с похожими именами и повторяющимся кодом внутри - не надо так...
е)
Это боже, храни короля, эквивалентно:
ж) В целом концепция TDD не была показана, человек, не знающий о TDD и увидевший Ваш ролик, подумает, что суть TDD в том, чтобы сначала написать кучу тестов, под начальное поведение, которое уже придумано (Ваш список реакций на разные ip), а потом просто взять и подобрать какую-то реализацию, которая магическим образом удовлетворит всем тестам (словно бы подойдет как ключ к замку)
На мой взгляд, это в корне не верно, с обучающей точки зрения. Стоило продемонстрировать полный путь от тривиальных решений, (false для пустого ip, false для ip с точками, true для локалхоста, false для любого элемента, который больше 255 в ip-шнике) при том, с каждым новым, добавляемым тестом, изменялся бы код реализации. Это бы продемонстрировало как изменяющиеся внешние факторы (желание заказчика, наше представление о предметной области) - может уточнять и специализировать код... при этом тесты которые уже созданы, являются всего навсего исполняемой документацией, которая будет сигнализировать о нарушении предположений, которые были описаны в тестах.
Таким образом можно было бы прийти к финальной версии регэкспа, которая вполне вероятно выглядела бы иначе, была разбита на понятные токены, и собиралась в компайлтайме.
5) Прощание - "Спасибо, за внимание, пока" - очень обрубило повествование, имхо стоило подвести к тому, что порой не все бывает так просто, что это может быть метод класса, а не свободная функция, и что метод этот не всегда будет возвращать какие-то значения... и что мол вот в следующий раз то мы и поговорим о том, как быть в такой ситуации.

В целом, не хочу, чтобы Вы негативно восприняли мой пост, Вы просили комментарии по видео, я их предоставил, желаю Вам успехов в этом несомненно нужном начинании.

0

Благодарю вас за уделённое время и за такую объективную критику. 100% вы написали не зря. Добавил ссылку на ваш пост в описание видео. Постараюсь со временем обдумать и учесть все замечания. Нужно какое-то время хорошенько поработать с Google Test, а потом записывать, если нужно и 2-ю версию этого вводного урока. Может быть будет серия уроков, которая будет знакомить с возможностями Google Test и Google Mock. Мне самому очень нравится такой формат, когда всё происходит на твоих глазах

Не бойтесь критиковать. Меня ничего не заденет, не обидет. Замечания, предложения и т.д. Желательно: как улучшить, примеры для следующих видео

Предложите какие-нибудь другие примеры для вводного (этот хорош?) и для следующих видео. Например, для ASSERT_NEAR, так как не могу придумать простой пример из практики, чтобы нужно было сравнить вещественные числа, которые сравниваются с дельтой. Хочется простые примеры, но в тоже время, чтобы тесты очевидно были необходимы

0

8Observer8, вы этот плагин не ставили?
http://gres.biz/qtc-gtest/
Что-то пока не очень разобрался, как с ним работать...

0

Кажется, разобрался с плагином. Ему нужен проект обычного, а не консольного приложения, то есть в файле .pro не должно быть CONFIG += console.

0