tdd UnitTest
Личный опыт разработки библиотеки с покрытием unit тестами. На момент начала работы, я располагал подробной UML диаграммой, которая долго обсуждалась и корректировалась, в итоге unit тесты ни разу не вынудили изменить класс для того, чтобы он стал проще тестируем. Перед началом работы обнаружили, что в команде 3 разных взгляда на то, как писать тесты, в итоге пришли к соглашению по написанию тестов к классу. Красные полоски до implementation и зелёные после поднимают боевой дух. А вот когда вносишь исправление ошибки (в одну строчку), не пойманной тестами, и ради этого нужно написать ещё тесты в гораздо большее количество строк — боевой дух падает. Ближе к релизу поведение класса претерпевало изменения, а его интерфейс почти не изменялся, в итоге куча unit тестов, тестирующих специфичные ситуации, отправлялась в корзину (может я плохо их писал, а может тесты действительно выступают в таких случаях тяжелым грузом, пока не решил). Любые изменения класса при слабой связанности и взаимодействии через события могут привести к устареванию большого числа unit тестов, а это без внимания не должно оставаться. Порой тесты в полтора раза или больше превышают размеры тестируемого класса, а уверенности в том, что они покрыли все ситуации и баги, у меня никогда нет. Успешный тест не говорит о стабильности работы метода в приложении. Ни разу не встретил в статьях про unit тесты напоминание о том, что с затратами на их написание и поддержку прийдётся считаться а ведь вопрос о преимуществах использования unit тестирования стаёт более остро. Были случаи, когда я исправлял неработающий тест по работающему методу :) и мне за них стыдно. Конкретно в этом случае выгоды от моей реализации tdd не очевидны, в отличии от проблем этой реализации. Списывая на плохую реализацию буду практиковать дальше.