TDD: нарушает все существующие тестовые примеры при рефакторинге кода.

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

Это определенно показатель того, что что-то идет не так. Популярное определение рефакторинга звучит примерно так: это

РЕФАКТОРИЯ - это дисциплинированная методика реструктуризации существующего тела кода, изменения его внутренней структуры без изменения его внешнего поведения.

Частично суть модульных тестов заключается в том, что модульные тесты оценивают внешнее поведение вашей реализации. Неудачный модульный тест указывает на то, что изменение реализации каким-то образом изменило внешне наблюдаемое поведение.

В этом конкретном случае похоже, что вы изменили свой API - в частности, вы удалили конструктор по умолчанию, который был частью API для создания экземпляров SalaryManager; это не «рефакторинг», это изменение в обратном направлении.

Нет ничего плохого в том, чтобы вводить новых соавторов во время рефакторинга, но вы должны делать это так, чтобы не нарушать текущий контракт API.

public class SalaryManager
{
    public SalaryManager(ISalaryCalculator salaryCalculator, ISalaryMessageFormatter _messageFormatter){
        _salaryCalculator = salaryCalculator;
        _messageFormatter = messageFormatter;
    }

    public SalaryManager() {
        this(new SalaryCalculator(), new SalaryMessageFormatter())
    }

где SalaryCalculator и SalaryMessageFormatter должны быть реализациями, которые производят то же наблюдаемое поведение, что и у вас изначально.

Конечно, бывают случаи, когда нам нужно провести обратное изменение. Однако «рефакторинг» не подходит для этого случая. Во многих случаях вы можете достичь желаемого результата в несколько этапов: сначала расширение вашего API новыми тестами (рефакторинг для удаления дублирования с существующей реализацией), затем удаление тестов, оценивающих старый API, и, наконец, удаление старого API.

Эта проблема возникает, когда рефакторинг изменяет обязанности существующих модулей, особенно за счет введения новых или удаления существующих модулей.

Вы можете сделать это в стиле TDD, но вам необходимо:

1. делать небольшие шаги (это исключает изменения, которые извлекают оба класса одновременно)
2. рефакторинг (сюда входит и тестовый код рефакторинга!)

Отправная точка

В вашем случае у вас есть (я использую более абстрактный синтаксис, похожий на Python, чтобы иметь меньше шаблонов, эта проблема не зависит от языка):

class SalaryManager:
    def CalculateSalaryAndSendMessage(daysWorked, monthlySalary):
      // code that has two responsibilities calculation and formatting

У вас есть тестовый класс для этого. Если у вас нет тестов, вам нужно сначала создать эти тесты (здесь вы можете найти Эффективная работа с устаревшим кодом действительно полезна) или во многих случаях вместе с некоторым рефакторингом, чтобы иметь возможность еще больше реорганизовать ваш код (рефакторинг - это изменение структуры кода без изменения его функциональности, поэтому вам необходимо пройти тестирование чтобы убедиться, что вы не измените функциональность).

class SalaryManagerTest:
    def test_calculation_1():
      // some test for calculation

    def test_calculation_2():
      // another test for calculation

    def test_formatting_1():
      // some test for formatting

    def test_formatting_2():
      // another test for calculation

    def test_that_checks_both_formatting_and_calculation():
      // some test for both

Извлечение расчета в класс

Теперь давайте вам, что вывести за расчет ответственности за класс.

Вы можете сделать это сразу, не меняя API SalaryManager. В классическом TDD вы делаете это маленькими шагами и запускаете тесты после каждого шага, примерно так:

1. извлечь вычисление в функцию (скажем, calculateSalary) от SalaryManager
2. создать пустой SalaryCalculator класс
3. создать экземпляр класса SalaryCalculator в SalaryManager
4. переместить calculateSalary в SalaryCalculator

Иногда (если SalaryCalculator просто и его взаимодействие с SalaryManager просто) вы можете остановиться на этом и вообще не менять тесты. Так что тесты для расчетов по-прежнему будут частью SalaryManager. С увеличением сложности SalaryCalculator будет сложно / непрактично тестировать его через SalaryManager, поэтому вам нужно будет выполнить второй шаг - также тесты рефакторинга.

Рефакторинг тестов

Я бы сделал что-то вроде этого:

1. разделить SalaryManagerTest на SalaryManagerTest и SalaryCalculatorTest в основном путем копирования класса
2. удалить test_calculation_1 и test_calculation_1 из SalaryManagerTest
3. оставьте только test_calculation_1 и test_calculation_1 в SalaryCalculatorTest

Теперь тестирует SalaryCalculatorTest тестовую функциональность для расчета, но делайте это через SalaryManager. Вам нужно сделать две вещи:

1. убедитесь, что у вас есть интеграционный тест, который проверяет, что расчет вообще происходит
2. измените SalaryCalculatorTest, чтобы он не использовал SalaryManager

Интеграционный тест

1. Если у вас еще нет такого теста (test_that_checks_both_formatting_and_calculation может быть таким тестом), создайте тест, который выполняет некоторые простые варианты использования, когда вычисление задействовано из SalaryManager
2. Вы можете переместить этот тест на SalaryManagerIntegrationTest, если хотите

Сделать SalaryCalculatorTest использовать SalaryCalculator

Тесты в SalaryCalculatorTest - это все о расчетах, поэтому даже если они имеют дело с менеджером, их суть и важная часть - это ввод данных для расчета, а затем проверка его результата.

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

Тест на расчет может выглядеть так:

class SalaryCalculatorTest:

    def test_short_period_calculation(self):
       manager = new SalaryManager()
       DAYS_WORKED = 1
       result = manager.CalculateSalaryAndSendMessage(DAYS_WORKED, SALARY)
       assertEquals(result.contains('Salary cannot be generated'), True)

Здесь есть три вещи:

1. подготовка объектов к испытаниям
2. призыв к действию
3. проверка результата

Обратите внимание, что такая проверка каким-то образом проверяет результат расчета. Это может сбивать с толку и хрупко, но каким-то образом это поможет. Поскольку должен быть какой-то внешне видимый способ отличить, как закончился расчет. В противном случае (если это не дает видимого эффекта) такой расчет не имеет смысла.

Вы можете выполнить рефакторинг так:

1. извлеките создание manager в функцию createCalculator (можно называть это так, поскольку объект, который создается с точки зрения тестирования, является калькулятором)
2. переименовать manager -> sut (тестируемая система)
3. извлечь manager.CalculateSalaryAndSendMessage вызов в функцию `вычислить (калькулятор, дни, зарплата)
4. извлеките чек в функцию assertPeriodIsTooShort(result)

Теперь тест не имеет прямого отношения к менеджеру, он отражает суть тестируемого.

Такой рефакторинг должен выполняться со всеми тестами и функциями в этом тестовом классе. Не упустите возможность повторно использовать некоторые из них, например createCalculator.

Теперь вы можете изменить, какой объект создается в createCalculator и какой объект ожидается (и как выполняется проверка) в assertPeriodIsTooShort. Уловка здесь в том, чтобы по-прежнему контролировать размер этого изменения. Если он слишком большой (то есть вы не можете сделать тест зеленым после изменения в течение пары минут в классическом TDD), вам может потребоваться создать копию createCalculator и assert... и использовать их сначала только в одном тесте, а затем постепенно заменять старые с одним в других тестах.

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

Это правда, что модульный тест нужно изолировать. Это не означает, что агрегат необходимо полностью изолировать. Сам тест нужно изолировать от других тестов. Это означает, что тесты должны зависеть друг от друга, и должна быть возможность запускать их отдельно или даже параллельно.

Соответствующий модуль для модульного теста должен быть прецедентом. Вариант использования - это особенность вашего приложения. В движке блога создание сообщения в блоге - это вариант использования. В системе бронирования отелей найти свободный номер - это один из вариантов использования. Обычно вы найдете для них точку входа в так называемые службы приложений. Это та степень детализации, к которой вы должны стремиться. Избавьтесь от уродливых внешних зависимостей, таких как базы данных, файловые системы и внешние службы. Если вы реорганизуете внутреннюю структуру вашего приложения, тест не сломается, потому что вы не измените поведение варианта использования. Хотите разделить или объединить классы в своем домене? Вариант использования будет стабильным. Измените способ взаимодействия объектов домена друг с другом. Тест остается зеленым.