Ага, главное не забывать, что он недостежим :D
Поэтому важны тенденции, а не абсолютные показатели.
Цитата
Оно достаточно легко и чуть сложнее пока кодовая база небольшая, а потом объём тестов и говнокода становится настолько большим, что усилия на сопровождение этого всего начинают перевешивать пользу от него.
Не свидетельствует ли это о хреновой декомпозиции?
Значит нужно его добавить как только обнаружили что-то.
И вправду, как я об этом не подумал. А почему бы сразу в коде не поправить?
Так ты правишь и там и там, просто наличие теста позволит тебе в следующий раз, когда сломаешь, заметить это на более ранней стадии.
Цитата
А поломки совершенно, на первый взгляд, не связанных тестов из-за изменений в других тестах не встречал?
Встречал. И это всегда были или хреновые тесты или хреновая подсистема или хреновая декомпозиция и кривые связи.
То есть опять же некий признак, что явно идет не так, как хотелось бы :)
В общем, если покажешь код, который не нуждается в тестирвании, будет неплохо.
filter odd |> map (* 2) |> reduce (+)
Ну и почему на это не стоит написать тест? Ты ведь можешь в случае правок учесть не все места, где он используется. А тест проверит, что все контракты соблюдены.
Цитата
Не, я ж не против наличия автотестов, но пусть их и пишут тестировщики/бизнес-аналитики/постановщики-задач, но TDD-то не про это.
На моем опыте всегда было лучше, когда разрабы продукта писали сами unit-тесты и активно участвовали в разработке автотестов на других уровнях. Но не буду утверждать, что это всегда так.
Так ты правишь и там и там, просто наличие теста позволит тебе в следующий раз, когда сломаешь, заметить это на более ранней стадии.
И это не сферический пример в вакууме. У меня сейчас автотесты "опаздывают" чуть по разработке продукта (догоняем, но пока не догнали). Так это уже приводило несколько раз к тому, что одни и те же вещи уже несколько раз отламывали в продукте :D
