Застрял в дилемме модульного тестирования

Question

Несколько вопросов о юнит-тестировании.

Допустим, у меня есть класс, для каждого метода которого я пишу несколько модульных тестов.

Что происходит, когда я решаю изменить дизайн так, чтобы этот класс больше не существовал, но его функциональность должна быть смешана с другими классами?Тогда все юнит-тесты устаревают, верно?Мы ничего не можем с этим поделать.

Тогда, если мы изменяем дизайн довольно часто, как это происходит на практике, мы должны в основном писать одни и те же тесты снова и снова.Как этого избежать?

Можно было бы избежать этого, протестировав модульные классы, которые никогда не меняются, а все остальные полагаются на интеграционное тестирование в черном ящике, но является ли это правильным подходом?*

Answer 1

Прежде всего, хороший дизайн, основанный на твердых требованиях, не должен требовать серьезных изменений в Class.

. Если вам нужно часто менять, и вы все еще хотите принять Unit Testing, выу вас нет другого выбора, кроме как выбрать более сложный способ модульного тестирования каждый раз, когда вы вносите изменения.Не исключение.

Answer 2

Вы можете создать фасад, интерфейс которого не меняется, в то время как реализация может измениться в соответствии со спецификациями вашего класса.

Но в таком случае, почему бы не принять интерфейс фасада для самого класса?