Где задаётся поведение объектов в тестах?

Подходы к заданию поведения объектов в тестах

В тестировании, особенно при использовании библиотек для модульных (unit) и интеграционных тестов, поведение объектов задаётся через различные техники, зависящие от типа теста и конкретных фреймворков. Основные подходы включают использование моков (mocks), стабов (stubs), фейков (fakes) и прямое создание объектов с заданными состояниями.

Моки и стабы для имитации поведения

Для тестирования взаимодействия между объектами часто применяются библиотеки, такие как Moq, NSubstitute или FakeItEasy в C#. Они позволяют создавать объекты с предопределённым поведением, чтобы изолировать тестируемый компонент от внешних зависимостей.

Пример с использованием Moq для задания поведения метода

using Moq;
using Xunit;

public interface IRepository
{
    string GetData(int id);
}

public class Service
{
    private readonly IRepository _repository;
    
    public Service(IRepository repository)
    {
        _repository = repository;
    }
    
    public string ProcessData(int id)
    {
        var data = _repository.GetData(id);
        return data.ToUpper();
    }
}

[Fact]
public void ProcessData_ShouldReturnUpperCase()
{
    // Создание мока интерфейса IRepository
    var mockRepository = new Mock<IRepository>();
    
    // Задание поведения метода GetData: при вызове с id = 1 возвращает "test"
    mockRepository.Setup(repo => repo.GetData(1)).Returns("test");
    
    // Использование мока в тестируемом сервисе
    var service = new Service(mockRepository.Object);
    
    var result = service.ProcessData(1);
    
    Assert.Equal("TEST", result);
}

В этом примере:

• Мок объекта IRepository создаётся через Mock<IRepository>.
• Задание поведения метода GetData выполняется через Setup, где указывается, что при вызове с параметром 1 возвращается строка "test".
• Это позволяет тестировать метод ProcessData без реальной реализации IRepository.

Создание объектов с конкретным состоянием

В некоторых тестах, особенно при интеграционном тестировании или тестировании DTO (Data Transfer Objects), поведение задаётся напрямую через инициализацию объектов с нужными данными.

Пример тестирования валидации модели

using FluentValidation;
using Xunit;

public class UserModel
{
    public string Name { get; set; }
    public int Age { get; set; }
}

public class UserValidator : AbstractValidator<UserModel>
{
    public UserValidator()
    {
        RuleFor(user => user.Name).NotEmpty();
        RuleFor(user => user.Age).GreaterThan(0);
    }
}

[Fact]
public void UserModel_ShouldBeValid()
{
    // Создание объекта с заданными свойствами
    var user = new UserModel { Name = "John", Age = 25 };
    
    var validator = new UserValidator();
    var result = validator.Validate(user);
    
    Assert.True(result.IsValid);
}

Здесь объект UserModel создаётся с конкретными значениями Name и Age, что определяет его поведение при валидации.

Фейки для замены сложных зависимостей

Фейковые объекты — это легковесные реализации, заменяющие реальные сервисы, например, для имитации базы данных или внешних API.

Пример фейка для репозитория

public class FakeUserRepository : IUserRepository
{
    private readonly List<User> _users = new List<User>();
    
    public void Add(User user)
    {
        _users.Add(user);
    }
    
    public User GetById(int id)
    {
        return _users.FirstOrDefault(u => u.Id == id);
    }
}

[Fact]
public void AddUser_ShouldStoreInRepository()
{
    var fakeRepository = new FakeUserRepository();
    var service = new UserService(fakeRepository);
    
    var user = new User { Id = 1, Name = "Alice" };
    service.AddUser(user);
    
    var storedUser = fakeRepository.GetById(1);
    Assert.Equal("Alice", storedUser.Name);
}

Фейк FakeUserRepository предоставляет конкретное поведение для методов Add и GetById, позволяя тестировать UserService без реальной базы данных.

Резюме подходов

• Моки и стабы: Используются через библиотеки (Moq, NSubstitute) для задания поведения методов интерфейсов или абстрактных классов в модульных тестах. Ключевые методы — Setup, Returns, Throws.
• Прямое создание объектов: Подходит для тестирования моделей, валидаторов или простых сервисов, где объекты создаются с заданными свойствами.
• Фейки: Представляют собой легковесные реализации зависимостей для интеграционного тестирования, имитируя поведение реальных компонентов.
• Конфигурация в тестовых классах: В xUnit, NUnit или MSTest поведение может задаваться в методах установки (например, в SetUp или конструкторах тестовых классов).

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