Настройка AutoMock с AutoFixture Data Theories

Хорошо, как было дано в моем другом вопросе, AutoMoq не использует AutoFixture по умолчанию. Это нормально и легко решается путем настройки и настройки ReturnsUsingFixture.

Но можно ли это настроить с помощью Auto Fixture Data Theory?

Итак, у нас есть собственный AutoDataAttribute, который я назову [MyAutoData]. И там мы вызываем и настраиваем множество настроек, таких как AutoConfiguredMoqCustomization, настраиваем его для создания контроллеров webapi и регистрируем множество пользовательских генераторов. Таким образом, мы смогли вытащить ПОЧТИ всю стандартную конфигурацию в несколько основных файлов конфигурации. Мы даже установили атрибут MyAutoData для системных тестов, поэтому, если вы запросите, скажем, Id<Account>, он создаст новую учетную запись, используя фактические вызовы webapi, и вернет действительный идентификатор учетной записи.

Но как вы можете справиться с этим для настройки возврата метода AutoMoq? Вот пример:

    [Theory, MyAutoData]
    public async Task Test(Mock<ICqrsService> mockService, TheRequest request) 
    {
        mockService.Setup(service => service.CreateAsync<TheRequest>(It.IsAny<TheRequest>(), It.IsAny<CancellationToken>()))
        .ReturnsAsync(result); // or similar car with ReturnUsingFixture
        /* now we can test */
    }

В любом другом случае мы смогли переместить такую ​​конфигурацию в MyAutoData (или в класс, который он вызывает). Но для AutoMoq я не вижу, как это должно работать. Мы не можем сделать приспособление.

Есть ли способ запустить метод установки после того, как AutoFixture сгенерирует элемент, но до того, как он будет доставлен в метод тестирования? Или есть способ настроить поведение AutoMoq, чтобы ВСЕГДА использовать .ReturnsUsingFixture(fixture)? Или я просто неправильно думаю об этой проблеме?


unit-testing c# xunit autofixture automoq
person Riplikash    schedule 21.10.2015    source источник

Ответы (2)


arrow_upward
4
arrow_downward

Метод IPostprocessComposer<T>.Do(Action<T>) позволяет для дальнейшей настройки образца после его создания.

В вашем случае вы можете использовать его внутри настройки, чтобы настроить общий метод для Test Double, чтобы вернуть объект, созданный AutoFixture:

public class FakeServiceCustomization : ICustomization
{
    public void Customize(IFixture fixture)
    {
        fixture.Customize<Mock<IService>>(composer =>
            composer.Do(fake =>
                fake.Setup(service => service.Create<Something>())
                    .ReturnsUsingFixture(fixture);
    }
}
person Enrico Campidoglio    schedule 23.10.2015

arrow_upward
4
arrow_downward

FWIW, я уже думаю, что AutoConfiguredMoqCustomization слишком неявно, на мой вкус. AutoFixture, однако, является проектом сообщества, и другие люди сочли его достаточно полезным для его реализации.

Я не думаю, что есть какая-то причина, по которой предназначенно AutoConfiguredMoqCustomization не устанавливает универсальные методы; Я думаю, причина проста в том, что это сложно сделать. Другими словами, дело не в том, что AutoFixture не будет делать это за вас, а в том, что он не может.

Все сказанное в духе GOOS, я думаю, вам следует прислушаться к своим тестам. . Если тесты сложно написать, это обычно означает, что SUT сложно использовать. Это должно в первую очередь вызвать размышления о ТРИ, а не о тестах.

Не могли бы вы спроектировать SUT так, чтобы вам не нужна эта функция AutoFixture?

person Mark Seemann    schedule 24.10.2015