Другая сторона медали или про недостатки юнит-тестирования
[unable to retrieve full-text content]
И здесь, и в других местах в Сети есть масса статей, пропагандирующих автоматическое тестирование вообще и unit-тесты в частности. В статьях расписываются преимущества тестирования, использование его для устранения хрупкого кода, увеличения качества, миграции со старых систем на новые, рефакторинга. И, одновременно, нигде почти не упоминается об их недостатках, а ведь в инженерии нет «серебряных пуль»!
На самом деле «серебряные пули» есть, но их изобрели ещё первые инженеры, и они воспринимаются нами как скучные банальности: «мойте руки перед едой», «вытирайте ноги», «структурируйте код», «не пишите без отступов», «локализируйте состояние» и т.д. Тем не менее, тесты — это не «серебряная пуля», а один из эффективных и широко используемых инструментов, а значит, у него есть недостатки.
В этой заметке я попытаюсь структурировать и выписать именно недостатки тестов, в основном юнит-тестов. О достоинствах я постараюсь не писать, ведь об этом уже и так много материалов, только руку протяни. Разумеется, где-то я неизбежно что-то важное забуду, а где-то буду чересчур сгущать краски. Поэтому просьба рассматривать эту статью скорее как приглашение к беседе, чем что-то законченное. С моей точки зрения тема вполне назрела, и поэтому очень хотелось бы её обсудить в деталях.
Почему функциональное программирование? Так тестируем же мы почти исключительно функции.
Раскрыть тему
