TDD

[sergek]

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

[xokc]

Лол, то есть у вас даже отдела тестирования нет? Какое счастье, что люди типа вас не работают на биржах/не пишут ПО для АЭС/самолетов.

Я может сильно чью то уверенность в безопасности АЭС/самолетов сейчас подорву, но на самом деле в наших предприятиях в подавляющем случае таких не то чтобы подразделений, а и должностей нет. Я, по крайней мере, ни в одном из многих известных мне лично организаций весьма схожего профиля тестировщика (в современном понимании этого слова) не видел. И уж о TTD там точно никто не задумывался. Отдел технического контроля, да есть. Но у него СОВСЕМ другие функции.

[Bepec]

Что и говорить, если должности "программист" нет... Есть инженер, старший инженер и техник

[Igors]

Не, ну объявить "фигня, понты" всегда успеется. Я пытаюсь настроиться позитивно и понять светлые стороны

...ну что же в ней хорошего?
Ну что дурдом по ней плачет - это ясно.
Ножки... ножки как у козла рожки...

(классика советского кино)

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

Также меня смущает как отрабатываются более крупные, не побоюсь этого слова, "архитектурные" изменения. Напр то же чтение obj файла. Поначалу решил хранить вертексы и фейсы просто в контейнерах. Ну ладно, сделал.  Потом выяснилось что так не очень хорошо, напр для рисования с OpenGL. Переделал, теперь вместо контейнеров класс который знает что делать с геометрией. А как же с массой написанных тестов   Шо, опять все по новой?  

PS я вот к примеру не смог ответить на вопрос - как сделать тест, имитирующий реакцию пользователя (щелчок кнопок, глобальные клавиши, открытие нескольких окон, ввод данных, запись данных).

Насколько я понял, это к TDD отношения не имеет, это "просто тест". А что без тестирования и отладки ничего не живет - то ясно

[Авварон]

Также меня смущает как отрабатываются более крупные, не побоюсь этого слова, "архитектурные" изменения. Напр то же чтение obj файла. Поначалу решил хранить вертексы и фейсы просто в контейнерах. Ну ладно, сделал.  Потом выяснилось что так не очень хорошо, напр для рисования с OpenGL. Переделал, теперь вместо контейнеров класс который знает что делать с геометрией. А как же с массой написанных тестов   Шо, опять все по новой?  

Ну это значит, что вы не продумали использование. Очевидно, что должен быть класс с методами load/save(?) возвращающими как-то ошибку. И должен быть файл с тестом на этот класс. Если же у вас в левом месте ф-ия, к-ая читает данные в пачку контейнеров, принимая их по ссылке - это кривая "архитектура" by definition.
То, что АПИ класса меняется - это нормально. И тесты вам помогут его поменять, а не помешают. Добавили новое АПИ - исправили тесты, убедились, что работает, перешли на новое АПИ в коде, удалили старый. Можно даже не запускать приложение - 90% что регрессий вы не внесли. В случае отстутствия теста вам придется разбираться где вы там что забыли инициализировать по портянкам коллстеков в 60 вызовов.

[Igors]

Ну это значит, что вы не продумали использование. Очевидно, что должен быть класс с методами load/save(?) возвращающими как-то ошибку. И должен быть файл с тестом на этот класс. Если же у вас в левом месте ф-ия, к-ая читает данные в пачку контейнеров, принимая их по ссылке - это кривая "архитектура" by definition.

Мне кажется это решение (пачка контейнеров) не заслуживает осуждения. Во всяком случае именно так делают во многих open sources. С год назад тут показывалось как круто это сделать на boost::spirit - и тоже была бааальшая пачка   Достоинство obj текстовика - что вот так "тыц и готово" проходит. Конечно капитальным такое решение не назовешь, но часто большего и не требуется.

То, что АПИ класса меняется - это нормально. И тесты вам помогут его поменять, а не помешают. Добавили новое АПИ - исправили тесты, убедились, что работает, перешли на новое АПИ в коде, удалили старый. Можно даже не запускать приложение - 90% что регрессий вы не внесли. В случае отстутствия теста вам придется разбираться где вы там что забыли инициализировать по портянкам коллстеков в 60 вызовов.

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

[Old]

Мне кажется это решение (пачка контейнеров) не заслуживает осуждения. Во всяком случае именно так делают во многих open sources. С год назад тут показывалось как круто это сделать на boost::spirit - и тоже была бааальшая пачка  

Не, там заполнялась структура ModelData.
Но вам говорят о другом... нужно продумывать удобные механизмы использования своих классов и тестировать эти api, а что там под капотом не должно влиять.

[Bepec]

Портянки каллстеков это именно плохая архитектура и к ТДД отношения не имеет... Просто не видно разницы - и в том и в этом случае, проверять и тестировать надо всё.
Единственное что на мой взгляд ТДД может выявить - это невнимательность программиста, приведшая к ошибке в одной(1) функции. Но это проблема начинающий специалистов, отнюдь не середнячков.

PS почему меня так напрягает тест простых ф-ций - нигде у меня тестирование простых ф-ций не нужно. Ф-ция делает то-то и то-то и делает это хорошо. Вопрос в комплексе функций...

[Авварон]

boost::spirit

буст - говно

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

Я пишу класс, продумываю АПИ, делаю заглушки АПИ (ну там геттеры-сеттеры пишу сразу), пишу тесты на АПИ, потом заполняю класс. Это не совсем каноничное ТДД, которое требует написания теста до написания класса.
Макросы тестовых печатей - отличное тестирование:)

[Igors]

Макросы тестовых печатей - отличное тестирование:)

Которое никто не отменял  

Я пишу класс, продумываю АПИ, делаю заглушки АПИ (ну там геттеры-сеттеры пишу сразу), пишу тесты на АПИ, потом заполняю класс.  

Продумывание API развивается "по экспоненте". Тот же пример с obj - Вы можете и не знать что дальше делать с прочитанным, поэтому пока самое разумное - считать пачку контейнеров. Ну их конечно можно объединить в класс и назвать напр ModelData, но сути это не меняет. Только потом, когда полезете в glDrawElements, Вы обнаружите что вертексы надо "расшарить". Вот тогда да - нужно думать над API, для этого появились инфа/основания.

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

[Old]

Продумывание API развивается "по экспоненте". Тот же пример с obj - Вы можете и не знать что дальше делать с прочитанным, поэтому пока самое разумное - считать пачку контейнеров. Ну их конечно можно объединить в класс и назвать напр ModelData, но сути это не меняет. Только потом, когда полезете в glDrawElements, Вы обнаружите что вертексы надо "расшарить". Вот тогда да - нужно думать над API, для этого появились инфа/основания.

Вы опять перепутали API и внутреннюю реализацию.
К тому же это пример НЕ продумывания api вообще, от слова "совсем". Все что вы собрались обнаруживать потом, вы должны были обнаружить в дали от компьютера с блокнотом в руках, только после этого вы вообще можете о чем-то начинать думать. С этого момента проектирование только начинается.
А подход, сесть за компьютер, набрать в редакторе "class MainWindow" и открыть ТЗ на проект, исключает этап проектирования. Но лучше так не делать.

[poru]

... внедрять ТДД на фирме или нет - решают не разработчики, а верхний менеджмент ...

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

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

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

Код

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

[Tuxford]

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

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

[poru]

Tuxford, читайте классические произведения. 

[Tuxford]

Tuxford, читайте классические произведения. 

Названия в студию.