Я придерживаюсь другого подхода к этому:
Какие у вас есть гарантии того, что ваш код верен? Или что это не нарушает предположение X, когда кто-то из вашей команды меняет func1 ()? Без юнит-тестов, поддерживающих вас «честно», я не уверен, что у вас есть большая уверенность.
Идея обновления тестов интересна. Сами тесты не часто должны меняться. У меня есть 3-кратный тестовый код по сравнению с рабочим кодом, и тестовый код был изменен очень немного. Это, однако, то, что позволяет мне хорошо спать по ночам, и то, что позволяет мне сказать клиенту, что я уверен, что смогу реализовать функциональность Y, не ломая систему.
Возможно, в научных кругах есть доказательства, но я никогда не работал в коммерческом мире, где кто-либо платил бы за такой тест. Однако я могу вам сказать, что это сработало хорошо для меня, заняло немного времени, чтобы привыкнуть к структуре тестирования, и написание теста заставило меня действительно задуматься о моих требованиях и дизайне, гораздо больше, чем когда-либо делал при работе в командах, которые не писали тесты.
Вот где это окупается: 1) Вы уверены в своем коде и 2) Вы обнаруживаете проблемы раньше, чем в противном случае. У вас нет специалиста по обеспечению качества, который говорит: «Эй, вы не потрудились проверить границы функции xyz (), не так ли? Он не может найти эту ошибку, потому что you нашел его месяц назад. Это хорошо для него, хорошо для вас, хорошо для компании и хорошо для клиента.
Ясно, что это анекдотично, но для меня это творит чудеса. Не уверен, что смогу предоставить вам электронные таблицы, но мой клиент доволен, и это конечная цель.