Изучать ли сразу TDD при изучении рельсов?

Написание тестов должно помогать писать более качественный код.

Сергей Протько: потому и в кавычках. К сожалению, не все [клиенты] это понимают и поначалу приходится

Виктор Выскребенцев: а скажите, пожалуйста, как Шерлок Холмс, какие тесты лучше использовать в Rails?

Виктор Выскребенцев: да, все зависит от клиента и от тестов. Скажем на типичном аутсорсинговом проекте юнит тестами код покрывать особо смысла нет (то есть он есть но не всегда и не для всего), можно обходиться хотя бы интеграционными и acceptance тестами. Есть есть QA тогда можно заставлять их писать acceptance сценарии на том же cucumber. И сохранится какая-то документация по проекту и польза будет если вы имплементить сценарии будете. QA всеравно себе где-то acceptance criteria пишут, правда хреново частенько и думаю что не все.

А если заказчик решит по BDD вести разработку вообще ништяк. Вообще плюс Ruby и RoR в том, что придамано масса инструментария для покрытия кода тестами с целью минимизировать время оного.

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

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

Словом... мне кажется что чем раньше тем лучше.

Сергей Протько: одно дело - изучать тестирование с самого начала и несколько другое - покрывать тестами несуществующий еще код. Первое новичку полезно, второе -- прямая дорога к фрустрации.

Евгений: не сказал бы. вы описываете свои ожидания от тестов и можете быстро проверить. Для обучения самое оно.

Сергей Протько: Ожидания от кода, конечно же.