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

Т.е., ты сначала пишешь, а потом думаешь над API? О проектировании не слышал?

И TDD позволит тебе сразу увидеть фейл в нем.

ты сначала пишешь, а потом думаешь над API?

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

О проектировании не слышал?

Обычно параллельно с проектированием создаётся прототип. Иначе можно напроектировать мертворожденное чудовище.

Соответственно нормальная последовательность разработки:

• прототип
• тесты
• улучшение прототипа (иногда со сломом структуры/рефакторингом)

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

То есть черновая заготовка конечно есть, но по ходу дела она уточняется и улучшается.

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

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

Тесты в TDD - это образцы реального применения API. Всё, что может понадобиться, уже учтено в процессе создания тестов. И изменения в API вносятся, только если изменено само техзадание.

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

Тесты в TDD - это образцы реального применения API.

У меня обычно тесты = примеры использования = документация. Вот только это не TDD, а скорее модульные и интеграционные тесты.

Тесты в TDD - это образцы реального применения API. Всё, что может понадобиться, уже учтено в процессе создания тестов.

Если писать что-то сложнее HelloWorld'a это совсем не так. Любое сложное приложение даст тебе кучу вариантов использования твоего API, о которых ты изначально даже не подозревал. Значит тесты быдут на явные и простые сценарии. А тут разницы между TDD и просто модульным тестированием уже не особо и заметна.

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

TDD диктует полное абстрагирование от реализации на момент тестирования.

На момент написания тестов то есть.

Тесты в TDD - это образцы реального применения API. Всё, что может понадобиться, уже учтено в процессе создания тестов.

Думаю, вы еще не достаточно глубоко поняли потенциал TDD. На самом деле, тесты - это конечный продукт, который нужно сдавать заказчику вместо программ.

Тесты в TDD - это образцы реального применения API

Тесты в TDD, это личные фантазии говнокодеров, не имеющие никакого отношения к реальному положению дел.

Всё, что может понадобиться, уже учтено в процессе создания тестов.

Ещё напой, что тесты пишет клиент, ага!

И изменения в API вносятся, только если изменено само техзадание.

Ясно! Теоретик!

На самом деле, тесты - это конечный продукт, который нужно сдавать заказчику

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

При всём уважении.

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

Клиенты вообще ничего не могут. Просто они думают, что их проблемы решают программы. А на самом деле, их проблемы решают тесты. А программы можно вообще не писать.

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

Это всё красиво, но проблемы клиентов решают программы. Тесты (tdd-шные) решают чуть больше чем ничего. Не могу сказать, что сталкивался со всеми ситуациями и раскладами, но по своему опыту:

1. Сначала надо изучить отрасль в которой плавает клиент - иначе все старания в жопу. 2. Сформировать в схемах _все_ бизнес-процессы, в которых участвует клиент. 3. Проектировка, проектировка, проектировка.

Я не против функциональных тестов, даже всеми конечностями ЗА! Но ставить тесты во главу угла - глупость.

Это может проканать в вебе, но в комплексной автоматизации, я бы за это ставил к стенке.

Мнение моё, и не факт что правильное.

Конечно неправильное. Бизнес-аналитика с методами написания кода не связана вообще никак. Как и тестирование (которое qa)