Вы правы.
Существует два способа рассмотрения рефакторинга, которые охватывают два несколько разных набора методов.
Первое - сделать идемпотентные изменения: исправить небольшую вещь внутри метода, чтобы конечный результат не изменился. Это, как сказано в статье, не требует изменений.
Второй (гораздо более интересный IMO) включает создание новых классов, изменение используемых шаблонов проектирования, а иногда и внесение огромных изменений в структуру класса (или классов). Это требует обновления тестов по мере продвижения .
Позвольте мне предложить другую интерпретацию: мне нужно по крайней мере два уровня тестирования:
Юнит-тесты , для метода испытаний. Эти тесты изменятся при рефакторинге производственного кода, чтобы следовать за модификацией кодов (их можно даже сделать до изменения, чтобы управлять им с помощью TDD)
Приемочные тесты (возможно, с использованием интегрированной среды тестирования, такой как FITnesse или JBehave, или простой JUnit, если нет) - эти тесты являются критериями высокого уровня для принятия, они должны не изменяются во время рефакторинга, и все же проходят в конце его. Фактически, они - ваша подвеска, ваше доказательство для успешного рефакторинга. Взломайте код, измените его, не задумываясь, и в конце концов, ваш приемный тест (ы) все равно должен пройти. Если они это сделают, вы можете идти. Если нет, это означает, что вы что-то сломали (или ваш тест был в первую очередь неправильным).
(Существует еще один уровень тестирования, который необходим: системные тесты или интеграционные тесты, но они выходят за рамки этого вопроса)