AutoFixture / AutoMoq игнорирует внедренный экземпляр / замороженный макет

Предполагая, что свойство SettingKey определено следующим образом, теперь я могу воспроизвести проблему:

public string SettingKey { get; set; }

Что происходит, так это то, что Test Doubles, введенные в экземпляр SettingMappingXml, прекрасно работают, но поскольку SettingKey доступен для записи, AutoFixture Auto- Свойства активируются и изменяют значение.

Рассмотрим этот код:

var fixture = new Fixture().Customize(new AutoMoqCustomization());
var sut = fixture.CreateAnonymous<SettingMappingXml>();
Console.WriteLine(sut.SettingKey);

Это печатает примерно так:

Клавиша настройки 83b75965-2886-4308-bcc4-eb0f8e63de09

Несмотря на то, что все тестовые двойники введены правильно, ожидания в методе Setup не выполняются.

Есть много способов решить эту проблему.

Защитить инварианты

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

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

Как минимум, я бы порекомендовал такую ​​альтернативную реализацию:

public string SettingKey { get; private set; }

С этим изменением моя репродукция проходит.

Опустить ключ настройки

Если вы не можете (или не хотите) изменить свой дизайн, вы можете указать AutoFixture пропустить установку свойства SettingKey:

IMappingXml sut = fixture
    .Build<SettingMappingXml>()
    .Without(s => s.SettingKey)
    .CreateAnonymous();

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

fixture.Customize<SettingMappingXml>(
    c => c.Without(s => s.SettingKey));
IMappingXml sut = fixture.CreateAnonymous<SettingMappingXml>();

Чтобы пойти дальше, вы можете инкапсулировать этот вызов метода Customize в Customization.

public class SettingMappingXmlCustomization : ICustomization
{
    public void Customize(IFixture fixture)
    {
        fixture.Customize<SettingMappingXml>(
            c => c.Without(s => s.SettingKey));
    }
}

Для этого вам потребуется создать свой Fixture экземпляр с этой настройкой:

IFixture fixture = new Fixture()
    .Customize(new SettingMappingXmlCustomization())
    .Customize(new AutoMoqCustomization());

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

public class TestConventions : CompositeCustomization
{
    public TestConventions()
        : base(
            new SettingMappingXmlCustomization(),
            new AutoMoqCustomization())
    {
    }
}

Это позволяет вам всегда создавать экземпляр Fixture следующим образом:

IFixture fixture = new Fixture().Customize(new TestConventions());

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

Наконец, поскольку похоже, что вы используете xUnit.net, вы можете использовать интеграцию AutoFixture с xUnit.net, но прежде чем вы это сделаете, вам нужно будет использовать менее императивный стиль управления Fixture. Оказывается, код, который создает, настраивает и внедряет ISettings Test Double, настолько идиоматичен, что имеет ярлык под названием Заморозить:

fixture.Freeze<Mock<ISettings>>()
    .Setup(s => s.Get(settingKey)).Returns(xmlString);

После этого следующим шагом будет определение настраиваемого атрибута AutoDataAttribute:

public class AutoConventionDataAttribute : AutoDataAttribute
{
    public AutoConventionDataAttribute()
        : base(new Fixture().Customize(new TestConventions()))
    {
    }
}

Теперь вы можете сократить тест до самого необходимого, избавившись от всего шума и позволяя лаконично выразить только то, что имеет значение:

[Theory, AutoConventionData]
public void ReducedTheory(
    [Frozen]Mock<ISettings> settingsStub,
    SettingMappingXml sut)
{
    string xmlString = @"
        <mappings>
            <mapping source='gcnm_loan_amount_min' target='gcnm_loan_amount_min_usd' />
            <mapping source='gcnm_loan_amount_max' target='gcnm_loan_amount_max_usd' />
        </mappings>";
    string settingKey = "gcCreditApplicationUsdFieldMappings";
    settingsStub.Setup(s => s.Get(settingKey)).Returns(xmlString);

    XElement actualXml = sut.GetXml();

    XElement expectedXml = XElement.Parse(xmlString);
    Assert.True(XNode.DeepEquals(expectedXml, actualXml));
}

Другие варианты

Чтобы исходный тест прошел успешно, вы также можете полностью отключить автоматические свойства:

fixture.OmitAutoProperties = true;

В первом тесте вы можете создать экземпляр класса Fixture с примененным AutoMoqCustomization:

var fixture = new Fixture()
    .Customize(new AutoMoqCustomization());

Тогда единственные изменения:

Шаг 1

// The following line:
Mock<ISettings> settingsMock = new Mock<ISettings>();
// Becomes:
Mock<ISettings> settingsMock = fixture.Freeze<Mock<ISettings>>();

Шаг 2

// The following line:
ITracingService tracing = new Mock<ITracingService>().Object;
// Becomes:
ITracingService tracing = fixture.Freeze<Mock<ITracingService>>().Object;

Шаг 3

// The following line:
IMappingXml sut = new SettingMappingXml(settings, tracing);
// Becomes:
IMappingXml sut = fixture.CreateAnonymous<SettingMappingXml>();

Вот и все!

Вот как это работает:

Внутри Freeze создает экземпляр запрошенного типа (например, Mock<ITracingService>), а затем внедряет его, поэтому он всегда будет возвращать этот экземпляр при повторном запросе.

Это то, что мы делаем в Step 1 и Step 2.

В Step 3 мы запрашиваем экземпляр типа SettingMappingXml, который зависит от ISettings и ITracingService. Поскольку мы используем Auto Mocking, класс Fixture будет предоставлять имитации для этих интерфейсов. Однако мы ранее внедрили в них Freeze, поэтому уже созданные макеты теперь поставляются автоматически.