korvin:
Это. Но это на прошлой работе. На текущей — нет TDD и так во многих случаях удобней.


ХЗ, бывает, что изменение требует значительно меньше кода, чем тестов, и приходится писать кучу однообразной мути, чтобы типа было покрыто тестами и т.п. Причём, ладно юнит-тесты, но функциональные были просто адом.

Как по мне, значимость автоматического тестирования несколько преувеличена, а иногда оно приносит больше вреда, чем пользы, например, провоцирует писать quick&dirty код (тесты ж всё равно отловят ошибки, а на их написание и так уходит куча времени, чтоб ещё его тратить на качественный код/архитектуру, а синюю фазу рефакторинга на практике часто игнорируют).

Конечно, это сильно зависит от сферы применения (всякое «mission-critical» ПО всё же лучше хорошо тестировать) и от «уровня» сервиса (например, фронтенд менее критичен к ошибкам, чем какие-нибудь РСУБД/ОС и прочая инфраструктура, которую использует сервис).


Я после работы в TDD-ориентированной компании пришёл к выводу, что моки вообще больше зло, чем добро, и не нужны. Стабы лучше. )

Добавлено 01.09.20, 15:58
Ещё раздражает мантра «тесты — это спецификация». Возникает вопрос: а почему бы не писать код декларативно, чтобы он выглядел как спецификация и не требовал тестов? Не, опять же, бывают случаи, когда какой-нибудь числодробильный код не декларативен ради оптимизации времени выполнения и/или памяти, такие функции разумно покрыть тестами, да, тем более, что обычно это достаточно независимые функции и мокать/стабать/вообще-создавать-сколько-нибудь-сложное-окружение там не нужно.

https://forum.sources.ru/index.php?showtopic=419507&view=findpost&p=3838062