TDD

[_Bers]

И еще... Никто не знает, в чем именно заключается тестирование, что является конечной целью и какие результаты следует получить. Принято считать тестирование законченным, если выполнение программы завершается кодом возврата 0, даже если исходные данные различаются хотя бы одним числом.
 

Размышления уровня джуниора. Если не знаете, то читайте умные книги. На такие дурацкие вопросы уже есть давно ответы.

судя по нашему последнему диалогу вы недалеко от этого джуна ушли:
не понимаете в чем заключается тестирование.

[_Bers]

Вопрос сторонникам технологии тестирования: Как вы будете тестировать вот этот случай?

Код

C++ (Qt)
 
float a = 123456789;
float b = 123456788;
qDebug() << a - b;
 

зависит от того, что именно нужно получить в результате.

[Racheengel]

Тестировать надо проблемные и потенциально проблемные места. А что должно быть параметрами и результатом, определяется контекстом задачи. Это невозможно формализовать и обобщить.

[_Bers]

Конечно приличный класс (или ф-ционал) без отладки (а значит и тестового кода) просто не пойдет (где-то да насвистел). Но TDD тут ни при чем, Вы говорите просто о нормальном тестировании. Далеко не для всех классов Вы будете его делать, далеко не всегда даже выносить тесты в отдельные файлы - может просто включите макросы тестовых печатей. Не верю что чтение obj начнете с теста "пустой файл", не будете Вы такой фигней заниматься  

кстати, а что такое "нормальное тестирование" ?

вот у меня ситуация возникла: есть стек технологий:
гуи, который ужассен, там не подкапаешься,
файловая система,
работа с реестром, много всякого винапи,
работа с сторонними утилитами, которые немножко чудят.
базы данных.

в совокупности, имеется приложение для администрирования базами данных.

и вот нужно было придумать, как весь этот корабль тестировать.

я сделал так:
1.
сначала покрыл тестами функционал компонентов работы с файловой системой.
там все просто: создать/удалить файл/каталог.
и что бы это выполнялось плюс/минус стабильно.
(аппаратными проблемами можно пренебреч)

2.
для гуя сбоку прилепил свою статическую систему сообщений,
что бы можно было "нажимать на кнопки" программно.
(MFC, родную систему сообщений для этих целей задействовать не получилось).


далее реализовал такую штуковину.

приложение запускается с аргументом командной строки:
в режиме тестирования, получает на входе текстовый файл с сценарием.

примерно такой дизайн:

Код:

подготовка:
каталог такой то - удалить.

предусловие:
каталога такого то быть не должно.

тест:
создать базу по имени "ля ля ля", в таком то каталоге.

постусловие:
проверка существования базы данных
проверка существования табличного пространства базы данных
проверка физического существования базы.

очистка:
удалить базу

постусловие:
базы такой то быть не должно
каталога такого то быть не должно.

вот это вот как называется?

[Tuxford]

Тестировать надо проблемные и потенциально проблемные места. А что должно быть параметрами и результатом, определяется контекстом задачи. Это невозможно формализовать и обобщить.

Очень интересный подход. Есть класс Foo, Zoo, Koo, Loo. Все в кучу как-то связано. Образована какая-то многопоточная библиотечка. А теперь вопрос: как убедится что все эти классы работают правильно.
Никто не говорит, что на функцию лишь возвращающую результат надо писать юнин-тест. Не надо сводить хорошую идею до маразма.
Еще вопрос. А если дебаг возможен только printf'ом, тогда как проверить правильность работы?

[Racheengel]

Очень интересный подход. Есть класс Foo, Zoo, Koo, Loo. Все в кучу как-то связано. Образована какая-то многопоточная библиотечка. А теперь вопрос: как убедится что все эти классы работают правильно.
Никто не говорит, что на функцию лишь возвращающую результат надо писать юнин-тест. Не надо сводить хорошую идею до маразма.
Еще вопрос. А если дебаг возможен только printf'ом, тогда как проверить правильность работы?

Этот подход продиктован практической целесообразностью. ЧТО и КАК тестировать - это специфика проекта, в одном случае нужен один способ, в другом - иной. Иногда и дебаг через принтф дает очень много. Вы же не применяете один и тот же std::vector<double>, например, на все случаи жизни? Почему с тестированием должно быть по другому?

[Tuxford]

Вы же не применяете один и тот же std::vector<double>, например, на все случаи жизни? Почему с тестированием должно быть по другому?

Потому что технологии тестирования уже давно отработаны. Изобретать велосипед нет нет смысла а не рассказывать что ТДД придумали коммерсанты.

[Racheengel]

Как Вы с помощью "некоммерческого" ТДД протеституете, например, коммуникацию с роботом? А GUI приложения? А систему, принимающую решения в реальном времени?

[Tuxford]

Как Вы с помощью "некоммерческого" ТДД протеституете, например, коммуникацию с роботом? А GUI приложения? А систему, принимающую решения в реальном времени?

Немного не то. Вы говорите о функциональных тестах.
Коммуникаци, можно проверить. К примеру я поднимал простенький ФТП, делал проверку аплоада, реализованного через curl. Тестится на ура. При желании можно пойти дальше. Написать можно забабахать ФТП, который будет симулировать все нужные ситуации. Тогда вообще красота.

Для тестирования гуйни есть другие фишки. К примеру тестить html страници можно с помощью Селениума. Но, еще раз повторю, что это уже функциональное тестирование, а не юнит.

[Racheengel]

Правильно! Вот и Вы пришли к тому же - ТДД не может быть применимо для тестирования всего подряд (о чем так любят говорить особо упоротые адепты и сейлс-менеджеры). От себя скажу даже больше - там, где мне довелось работать, я ни разу, никогда не видел и не слышал, чтобы от ТДД был какой-либо профит. Проблемы - да. Пользы - нет. Либо потеря денег, либо времени, либо того и другого.

[Igors]

Коммуникаци, можно проверить. К примеру я поднимал простенький ФТП, делал проверку аплоада, реализованного через curl. Тестится на ура. При желании можно пойти дальше. Написать можно забабахать ФТП, который будет симулировать все нужные ситуации. Тогда вообще красота.

Возможно это справедливо для Вашего круга задач, но это случай не общий. Вот выше я привел пример простенькой задачки - чтение obj файла. В упор не вижу какой здесь прок от юнит-тестов. Гораздо лучше попросить юзеров накидать obj-файлов и прогнать каждый, визуально наблюдая полученную модель. Баги будут (и много), но совсем не те что ловились бы тестированием.

[Tuxford]

Правильно! Вот и Вы пришли к тому же - ТДД не может быть применимо для тестирования всего подряд (о чем так любят говорить особо упоротые адепты и сейлс-менеджеры).

Сейл вообще не догадывается что это такое.

От себя скажу даже больше - там, где мне довелось работать, я ни разу, никогда не видел и не слышал, чтобы от ТДД был какой-либо профит. Проблемы - да. Пользы - нет. Либо потеря денег, либо времени, либо того и другого.

А я лично сам увидел. Особенно в больших проектах, с миллионами строк кода. В случае, когда жирная апликуха как-то интересно падает после 15 минут работы, с юнитестированием решается намного легче.
Или рефакторинг. Вот пример. Такого плана. Был себе движок для парсинга одного интересного файл. В моем случае информация о версиях. Номера версий изначально сохранялись в формате X.Y.Z. Тут сказали, что надо переделать на обычный X.Y.build. Как без юнит-тестов очень просто. Надо парсер версии переделать. Потом брать приложение, которое юзает это делать и проверять. Есть два приложения. Начали на одном тестить, вроде все хорошо. начали на втором тесть. Все хорошо. Дошло дело до приемочного тестирования. Тестировщики поковырялись и оказывается, что если к версии билда добавить буковку, хрен работает. Чтобы воспроизвести, надо сделать десяток телодвижений. Если бы были юнит-тесты, то скорее всего, там бы такой кейс был. А если не было, то добавить можно было проще. Т.е. когда уже поменяли функционал, запустил тесты и все. Минус одна проблема. Но нет, вместо того чтобы написать несколько простеньких строк текста, мы себе усложнили жизнь. Если бы таки случаев единицы. Ага, их немерено.

Проблемы - да. Пользы - нет. Либо потеря денег, либо времени, либо того и другого.

Проблема только одна: разработчикам лень писать примитивный код. В юинт-тестах ничего интеллектуального нет. В некоторой степени рутинная работа. Но так некоторые говорят что нафиг этот git.
По поводу потери времени, тысячу раз писал, что это компенсируется в будущем. Пример из одной конторки.
Когда только переходили на новый компилятор студии, сразу начинались проблемы. Любит мелкомягкий загрузит ненужной работой. Там где юнит-тесты были, проблемы решались в раз 5=-10(!) быстрее. И проблем было существенно меньше было. Старый код, где юнит-тестов не было, иногда отгрызал месяцы работы. 

Коммуникаци, можно проверить. К примеру я поднимал простенький ФТП, делал проверку аплоада, реализованного через curl. Тестится на ура. При желании можно пойти дальше. Написать можно забабахать ФТП, который будет симулировать все нужные ситуации. Тогда вообще красота.

Возможно это справедливо для Вашего круга задач, но это случай не общий. Вот выше я привел пример простенькой задачки - чтение obj файла. В упор не вижу какой здесь прок от юнит-тестов. Гораздо лучше попросить юзеров накидать obj-файлов и прогнать каждый, визуально наблюдая полученную модель. Баги будут (и много), но совсем не те что ловились бы тестированием.

Для вашего случае юнит-тестирование куда больше подходит. Куда проще накидать кучу маленьких файлов с определенной кривизной и проверять как ведется парсер в случае, скажем, отсутствие какого-то параметра. Или значение выходит за пределы. Или вообще файл подсунули не obj. Скажете такого не бывает? Недооцениваете изверей. 

[Igors]

Для вашего случае юнит-тестирование куда больше подходит. Куда проще накидать кучу маленьких файлов с определенной кривизной и проверять как ведется парсер в случае, скажем, отсутствие какого-то параметра. Или значение выходит за пределы. Или вообще файл подсунули не obj. Скажете такого не бывает? Недооцениваете изверей. 

Для какой-то "гипотетической" задачи можно доказать необходимость чего угодно. Поэтому я специально взял простенький пример, даже если Вы никогда с obj файлом не работали - через неск минут чтения вики Вам все станет ясно (надеюсь уровень хотя бы джуниора имеется  )

Думается в данном случае сочинять какие-то юнит-тесты - пустая трата времени. Вот примерно с чем Вы столкнулись бы на практике

- оказывается строки-то могут склеиваться слешем \
- оказывается индексы-то могут быть отрицательными
- оказывается одни фейсы могут иметь UV а др нет (противный случай)
и.т.д.

И вот, не зная этого, Вы наделали N тестов - ну и что, какая от этого польза? Надеяться что они как-то помогут при внесении изменений - так это в данном случае "стрельба по площадям"

[Авварон]

Каждый раз поражаюсь тому бреду, что пишет Igors.

[Tuxford]

Для вашего случае юнит-тестирование куда больше подходит. Куда проще накидать кучу маленьких файлов с определенной кривизной и проверять как ведется парсер в случае, скажем, отсутствие какого-то параметра. Или значение выходит за пределы. Или вообще файл подсунули не obj. Скажете такого не бывает? Недооцениваете изверей. 

Для какой-то "гипотетической" задачи можно доказать необходимость чего угодно. Поэтому я специально взял простенький пример, даже если Вы никогда с obj файлом не работали - через неск минут чтения вики Вам все станет ясно (надеюсь уровень хотя бы джуниора имеется  )

Думается в данном случае сочинять какие-то юнит-тесты - пустая трата времени. Вот примерно с чем Вы столкнулись бы на практике

- оказывается строки-то могут склеиваться слешем \
- оказывается индексы-то могут быть отрицательными
- оказывается одни фейсы могут иметь UV а др нет (противный случай)
и.т.д.

И вот, не зная этого, Вы наделали N тестов - ну и что, какая от этого польза? Надеяться что они как-то помогут при внесении изменений - так это в данном случае "стрельба по площадям"

Я не эксперт в obj формате. Привел пример то что прочем в педивикии.
Вот для этих оказывается иногда можно тоже добавлять тест кейсы.
Если считаете пустой тратой времени, то не пишите. Вот только когда дело дойдет до того что оказывается что-то поняли не так, не говорите что Вас не предупреждали
От тестов пользы никакой. В том смысле что, нового функционала не добавляет. Вот только когда будете запускать тесты хотя бы перед каждым пушем, тогда сами увидите пользу от юнит тестирования так через месяц - два.