Это тестовый запах для смешивания в реальной реализации и издевательства?

Question

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

Ниже моя реализация.

public void Consume(string email)
{
    if(_emailValidator.IsLocate(email))
    {
        var parsedLocate = _parser.Parse(email);

        // Insert locate in database
    }
    else if(_emailValidator.IsGoodNightCall(email))
    {
        // Notify email notifying them that a locate email requires attention.
        _notifier.Notify();
    }
}

Ниже приведен мой модульный тест.

// Arrange
var validator = new EmailValidator();
var parser = new Mock<IParser>();
var notifier = new Mock<INotifier>();
var consumer = new LocateConsumer(validator, parser.Object, notifier.Object);
var email = EmailLiterals.Locate;

// Act
consumer.Consume(email);

// Assert
parser.Verify(x => x.Parse(email), Times.Once());

Запах кода - смешивать макеты и реальную реализацию в модульных тестах? Кроме того, как всегда проверять, всегда ли метод abc() запускался один раз? Неправильно, если я добавляю новый модульный тест каждый раз, когда добавляю функцию в свой блок if. Похоже, если я продолжу добавлять к своему Consume методу, я создаю ловушку.

Спасибо.

Answer 1

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

Однако, в зависимости от типа объединяемых блоков, наличие большого количества таких типовИнтеграционные тесты могут быть вполне нормальными.

Кшиштоф Козмич недавно написал в блоге об этом, где он описывает, как Castle Windsor имеет очень мало юнит-тестов , но много интеграционных тестов AutoFixture также имеет большую долю этих типов интеграционных тестов.Я думаю, что наиболее важным моментом является то, что, как правило, интеграция не должна пересекать границы библиотеки .

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

Однако имейте в виду, что вы больше не тестируете устройство в изоляции , поэтому вы вводите соединение между устройствами, которое затрудняет изменениекаждый независимо .

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

Answer 2

> Is it a test smell to mix in real implementation and mocks?

Это интеграционный тест (объединение 2 или более модулей), а не единичный тест (тестирование одного модуля отдельно)

Мой ответ Нет : Я думаю, что в тесте интеграции нормально использовать макеты.

Answer 3

Я бы сказал, сильный да.Модульное тестирование не должно содержать зависимостей между компонентами.