>Покрытие тестами легаси кода даёт больше гарантии безопасности при изменениях и поддержке
Всё верно. Просто это точно не TDD ибо тут наоборот - сначала тест, а потом код и никак иначе! И по сравнению с TDD покрытие легаси unit-тестами не то что бесполезно, просто близко к пословице "скупой платит дважды" (один раз тестируя код руками без тестов, а позже покрывая его unit-тестами)
Пример, особенно при развитии системы, банальный. Вот был к примеру доступ на уровне команды, а появляется сущность "компания", и с правами менеджера можно смотреть по всем командам компании. И хорошие тесты позволят добавить пару проверок: тест на доступ менеджера компании и отрицательный кейс на несоответствие компаний. Остальные изменения только общие на инициализации базовых данных (явно репозитории и команды поменяются при введении новых сущностей).
Если юнит-тестами покрывать "богато", каждый кейс прописывать вручную отдельным тестом то при изменении доменной модели/репозитория придётся править каждый тест. Это я и называю "цементированием кода". Когда проще не менять, потому что иначе все тесты поломаются. А изменение тестов становиться очень дорогостоющим (из-за количества).
Чтобы в случае потери актуальности какого-то отдельного теста или набора тестов проще было его вообще полностью удалить и написать заново, чем рефакторить сами тесты.
Согласен. С другой стороны палка о двух концах. Если один и тот же код используется в разных тестах - легче вынести, поскольку в случае рефакторинга структурированный код отрефакторить значительно проще, чем в каждом тесте.
Просто получается что если все зависимости (семь в данном случае) мокать отдельно в тесте каждого хэндлера да ещё чтобы моки что-то вменяемое возвращали, количество копипаста убъёт возможности рекаторить эти зависимости... ((
>Покрытие тестами легаси кода даёт больше гарантии безопасности при изменениях и поддержке
Всё верно. Просто это точно не TDD ибо тут наоборот - сначала тест, а потом код и никак иначе! И по сравнению с TDD покрытие легаси unit-тестами не то что бесполезно, просто близко к пословице "скупой платит дважды" (один раз тестируя код руками без тестов, а позже покрывая его unit-тестами)
Пример, особенно при развитии системы, банальный. Вот был к примеру доступ на уровне команды, а появляется сущность "компания", и с правами менеджера можно смотреть по всем командам компании. И хорошие тесты позволят добавить пару проверок: тест на доступ менеджера компании и отрицательный кейс на несоответствие компаний. Остальные изменения только общие на инициализации базовых данных (явно репозитории и команды поменяются при введении новых сущностей).
Если юнит-тестами покрывать "богато", каждый кейс прописывать вручную отдельным тестом то при изменении доменной модели/репозитория придётся править каждый тест. Это я и называю "цементированием кода". Когда проще не менять, потому что иначе все тесты поломаются. А изменение тестов становиться очень дорогостоющим (из-за количества).
Согласен. С другой стороны палка о двух концах. Если один и тот же код используется в разных тестах - легче вынести, поскольку в случае рефакторинга структурированный код отрефакторить значительно проще, чем в каждом тесте.
Просто получается что если все зависимости (семь в данном случае) мокать отдельно в тесте каждого хэндлера да ещё чтобы моки что-то вменяемое возвращали, количество копипаста убъёт возможности рекаторить эти зависимости... ((