Что хотят услышать интервьюеры:

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

Определение:

Интерфейс сам по себе не содержит реализации, поэтому напрямую тестировать в нём нечего. Проверяют класс, который реализует Consumer, и убеждаются, что он корректно выполняет контракт интерфейса: вызывает нужные зависимости, обрабатывает данные и возвращает ожидаемый результат. Если Consumer — это компонент, принимающий сообщения или данные, то тесты должны проверять его реакцию на разные входные сценарии, включая ошибки и пустые данные.

Пример использования:

Допустим, есть интерфейс IConsumer, который обрабатывает сообщение и сохраняет результат через репозиторий. Тогда в тесте можно подменить репозиторий мок-объектом и проверить, что метод обработки был вызван правильно.

public interface IConsumer
{
    void Consume(string message);
}

public interface IRepository
{
    void Save(string value);
}

public class Consumer : IConsumer
{
    private readonly IRepository _repository;

    public Consumer(IRepository repository)
    {
        _repository = repository;
    }

    public void Consume(string message)
    {
        if (string.IsNullOrWhiteSpace(message))
            throw new ArgumentException("message is empty");

        _repository.Save(message.Trim());
    }
}

Пример теста на xUnit + Moq:

using Moq;
using Xunit;

public class ConsumerTests
{
    [Fact]
    public void Consume_ShouldSaveTrimmedMessage()
    {
        var repo = new Mock<IRepository>();
        var consumer = new Consumer(repo.Object);

        consumer.Consume("  hello  ");

        repo.Verify(r => r.Save("hello"), Times.Once);
    }

    [Fact]
    public void Consume_ShouldThrowOnEmptyMessage()
    {
        var repo = new Mock<IRepository>();
        var consumer = new Consumer(repo.Object);

        Assert.Throws<ArgumentException>(() => consumer.Consume("   "));
    }
}

Пояснение кода:

Код показывает, как тестировать не интерфейс, а его реализацию.

IConsumer задаёт контракт: метод Consume.
Consumer реализует этот контракт и зависит от IRepository.
В тесте создаётся mock IRepository, чтобы не ходить в реальную БД или внешнюю систему.
Первый тест проверяет, что строка обрезается и передаётся в Save ровно один раз.
Второй тест проверяет валидацию входных данных и ожидаемое исключение.

Такой подход позволяет изолировать логику Consumer и проверить его поведение без внешних зависимостей.

Ключевые моменты:

Сам интерфейс напрямую не тестируют, потому что в нём нет реализации.
Тестируют класс, который реализует интерфейс, и проверяют соблюдение контракта.
Для изоляции используют моки, стабы или фейки зависимостей.
Проверяют не только успешный сценарий, но и ошибки, пустые значения, граничные случаи.
Если Consumer связан с сообщениями или событиями, важно проверять корректность обработки входных данных и вызовов зависимостей.
Хороший unit-тест должен быть быстрым, детерминированным и не зависеть от внешних систем.

Каким образом можно применить модульное тестирование для проверки интерфейса Consumer?