Профессиональное
Лично я всю жизнь разрабатывал софт методом Intergity Test Driven ("поменял строчку - запустил всю систему с нуля, погонял в разных режимах и посмотрел, получилось ли то, что должно было получиться"), и потому не особо нуждался в юнит-тестах. Но в больших коллективах, где каждый отвечает только за свою строчку, и лишь Бог - за конечный продукт, они наверное нужны, чтобы прикрыть личную задницу. "К пуговицам претензии есть?".
Юнит-тесты, зачастую, работают против проекта, а не "за": любое внутреннее изменение кода (не меняющее поведение системы с точки зрения пользователя) часто заставляет менять, выкидывать или переписывать с нуля кучу тестов.
Внешнее поведение системы (типа АПИшки или интерфейса) стабильней, чем внутренняя архитектура кода.Потому юнит-тесты не нужно писать вообще, а функциональные тесты - напротив, писать нужно почти всегда.
UPD. Прочитав комментарии, я решил сформулировать следующую метафору о соотношении тестирования и разработки: пока пользователей мало, рулит разработка, когда пользователей много, на первый план выходит надежность системы, а следовательно, тестирование и минимизация рисков, вносимых очередными изменениями. В пределе относительная трудоемкость разработки в сравнении с тестированием стремится к нулю.
Юнит-тесты, зачастую, работают против проекта, а не "за": любое внутреннее изменение кода (не меняющее поведение системы с точки зрения пользователя) часто заставляет менять, выкидывать или переписывать с нуля кучу тестов.
Внешнее поведение системы (типа АПИшки или интерфейса) стабильней, чем внутренняя архитектура кода.Потому юнит-тесты не нужно писать вообще, а функциональные тесты - напротив, писать нужно почти всегда.
UPD. Прочитав комментарии, я решил сформулировать следующую метафору о соотношении тестирования и разработки: пока пользователей мало, рулит разработка, когда пользователей много, на первый план выходит надежность системы, а следовательно, тестирование и минимизация рисков, вносимых очередными изменениями. В пределе относительная трудоемкость разработки в сравнении с тестированием стремится к нулю.