А вы используете TDD в своих проектах?

А тебе зачем? Чаще всего на C++, Python, Java + знаю, но редко пользую ещё несколько. Или ты ждал ответа «на русском/английском»?

Красивый ответ, но хочется конкретики.

Ничего не ждал, просто поинтересовался. К сожалению не знаю больших Open Source проектов где это применяют и можно посмотреть на их код, не в курсе?

Глупости какие.

Быдлокодеры и индусы не используют TDD.

Ты как-то издалека заходишь. Тебя ткнуть носом в проекты на C++/Python или с TDD?

Ну я ж не программист, ага, примеры С/C++ проектов созданных с использованием TDD были бы интересны.

Есть SQLite, boost, httpd, graphviz, google chrome - это на C/C++. Большая часть подобного написана на Java.

примеры С/C++ проектов созданных с использованием TDD были бы интересны.

Есть SQLite, boost, httpd

И это TDD? O_o При том, что

schizoid> Не модульные тесты (функциональные, интеграционные), не регресс-тестирование, не test-first, а именно test driven?

По-моему, ты запутался в показаниях.

А как, по-твоему, должно проявляться ПРОЕКТИРОВАНИЕ в результирующем исходном коде? Или там заметка должна быть в ридми: «Вы, конечно, видите здесь только модульные тесты, но поверьте на слово, они были написаны в рамках TDD»?

Или там заметка должна быть в ридми: «Вы, конечно, видите здесь только модульные тесты, но поверьте на слово, они были написаны в рамках TDD»?

Должно быть что-то большее, чем «вы видите только модульные тесты, но поверьте, код был написан в рамках TDD».

Что ты пристал к юноше? Не убивай в нем веру в TDD! :)

В начале разработки, если слишком много неопределенностей:

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

Когда задача «простая» - TDD прокатит. Когда много неясностей - это будет напоминать попытку по теням на стене угадать звук 3D-модели.

Подобное в том или ином виде говорилось уже много раз. Ничего нового.

Если сильно обобщать подход, можно дойти до того, что прототип - это такой большой тест, ага.

«Ос - это такой большой полосатый мух»

Когда задача «простая» - TDD прокатит. Когда много неясностей - это будет напоминать попытку по теням на стене угадать звук 3D-модели.

Дабы по будоражить воображение скажу, что есть top-down, а есть bottom-up подход в написании тестов. Так вот TDD это bottom-up, то есть тесты на клиентское API пишутся в последнюю очередь.

А почему прототип нельзя писать через TDD?

Должно быть что-то большее, чем «вы видите только модульные тесты, но поверьте, код был написан в рамках TDD».

Например?

А почему черновики не делают начисто сразу? Потому что смысла нет, и лишнего времени тоже.

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

Я так понимаю, что для подобных случаев настоящие джедаи сначала пишут тесты для тестов.

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

Откуда такое правило? Никто не запрещает писать неправильный тест (помним, что операция написания теста относительно легкая).

Вообще в самом простом случае тест можно использовать как входную точку прототипа. В таком случае тест проверяет, что что-то запускается и не валится с эксепшеном :) О святые угодники, этот метод уже лет 50 применяют!

Только быдлокодеры и используют TDD.

Лгать здесь запрещено. Ты подонок.

Тот же sqlite я наблюдал с самого рождения. Никаким TDD там и не пахло, и тесты появились далеко не сразу.

Например, в git должна быть история, демонстрирующая идиотизм разработчиков (тесты вперед кода).

Я прототипы тоже использую(без тестов).

Так делай прототипы, а TDD используй уже после их выбрасывания для основной разработки. В чем проблема-то?

Не, они не осиливают даже простые юнит-тесты. Просто херачат говнокод и с пеной у рта утверждают, что не хотят тратить время на написание тестов.

Должно быть что-то большее, чем «вы видите только модульные тесты, но поверьте, код был написан в рамках TDD».

Например?

Например, «только проекты, использующие TDD, обладают свойством $X; проект $Y обладает свойством $X; следовательно, $Y написан с использованием TDD».

- на этапе прототипирования никакой особой легкости в тестах не будет, то есть времени вы потратите заметно больше, а не чуть-чуть
- кривые тесты приведут к тому, что вместо проработки задачи вы будете радоваться «движению вперед», а полную жопу обнаружите в самый последний момент.

Мне TDD кажется странноватой идеей. Тесты до появления кода можно написать для кода, поведение которого полностью понятно. Но много ли такого кода? Мне кажется, что нет. Любая разработка итеративна.

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

Многие варианты второго используют первое.

Проблем нет. Меня просили объяснить, что не так с TDD.

PS. А вот если я прототип не выбросил, а начал прорабатывать, то получается что нарушил методику TDD и все будет плохо :)

Agile как раз и тесно свялан с TDD. Юнит-тесты очень важная часть при гибкой разработке.

Мне TDD кажется странноватой идеей. Тесты до появления кода можно написать для кода, поведение которого полностью понятно. Но много ли такого кода? Мне кажется, что нет. Любая разработка итеративна.

Могу показаться диким, но я, вообще, не верю в успех «рационализации» такого творческого процесса как разработка программного обеспечения. Те или иные методики могут сыграть злую шутку и оказаться неэффективными, хотя люди вечно носятся с новыми «гениальными» методиками - сколько их уже прошло на моей памяти. Что касается тестов, то вижу от них пользу в том, что они заставляют еще раз задуматься о самом главном и сложном - о постановке задачи. Конечно, это совсем не значит, что постановкой задачи нельзя заниматься без этих чертовых тестов :)

Юнит-тесты гомосяцкие слишком мелочны, чтобы заставлять о чем-то задумываться. Они не на том уровне абстракции, где можно думать за архитектуру. Тесты это хорошо и важно. Юнит-тесты - говно и не нужно.

Только вот аджайл при использовании TDD вообще не обязателен.

Тесты до появления кода можно написать для кода, поведение которого полностью понятно.

С чего вдруг? Пишешь совсем маленький тест -> пишешь небольшой код, который заставит этот тест проходить -> расширяешь тест -> пишешь код, чтобы тест проходил и т.д.

Если вы не выбросили прототип, то вы нарушили методику разработки с использованием прототипов.Т.к. прототип по определению выбрасывается.

Программирование - такая же инженерная специальность, как и другие. Творчества там не больше, чем в любой другой инженерной деятельности.

Вы просто быдлокодер.

Пишешь совсем маленький тест -> пишешь небольшой код, который заставит этот тест проходить -> расширяешь тест -> пишешь код, чтобы тест проходил и т.д.

Это настолько общее описание, что под него подходит любой процесс разработки. Мы что - как господин Журден, всю жизнь говорим прозой^W^Wиспользуем TDD?

С прототипами есть ровно 2 варианта - выбрасывать и прорабатывать. Если вашими канонами предусмотрено только выбрасывание - это не мои пролемы :)

Только вот аджайл при использовании TDD вообще не обязателен.

Это да.

Сейчас придут математики и и расскажут что в ней творчества не меньше чем в музыке.
ИМХО, все зависит от подхода.

Это и есть краткое описание сути TDD. Если у вас короткие циклы разработки и сначала вы пишите тест, который не проходит, а потом код, который заставляет тест проходить, то да, вы используете TDD.

Если у вас короткие циклы разработки

Длинные, состоящие из множества коротких.

Нет, просто у вас странное понимание прототипов. Кто вас такому научил? Прототип делается на выброс. Даже если он успешен. Ибо если не выбрасывать, то вы будете или перегружать прототип, или основывать основной код на сыром и непродуманном архитектурно прототипе.

Это вы передергиваете просто. Тесты совершенно ортогональны и не мешают «проработке задачи».

Замечательно. Так в чем вы видите проблему при использовании TDD? Короткие циклы разбиваете еще на более мелкие стадии, каждую начинаете с теста на то, что собираетесь сделать.

Собственно, суть такова:

• начинаем с написания теста, который пишется в объеме, необходимом и достаточном для того, чтобы тест не проходил
• новый код пишется после того, как будет написан тест, который не проходит
• новый код пишется только в том объеме, который достаточен для прохождения теста

Все остальное - уже менее важно.