Início / coding / Perguntas / 79315588
Accepted
Ivan Petrov
Asked: 2024-12-29 20:30:42 +0800 CST

Como usar atributos AutoFixture para obter referência FakeTimeProvider quando meu SUT depende de TimeProvider

  • 772

Digamos que eu tenha um Serviceque tenha uma dependência em TimeProvider.

O que faço agora para configurar o uso do FakeTimeProviderAutoFixture e do Moq para meus testes é:

public class FakeTimeProviderCustomization : ICustomization {
    public void Customize(IFixture fixture) {
        fixture.Customize<TimeProvider>
            (c => c.FromFactory(() => new FakeTimeProvider()));
    }
}

public class MoqAutoDataAttribute : AutoDataAttribute {
    public MoqAutoDataAttribute()
        : base(() => new Fixture()
        .Customize(new AutoMoqCustomization())
        .Customize(new FakeTimeProviderCustomization())
        ) {
    }
}

[Theory, MoqAutoData]
public async Task Test_TimeRelatedStuff(
    [Frozen] TimeProvider timeProvider,
    Service sut) {
    
    ...
    var fakeTimeProvider = timeProvider as FakeTimeProvider;
    ...

Posso evitar o elenco FakeTimeProviderque tenho que fazer toda vez?

c#

1 respostas

  1. Best Answer

    Você pode usar a MatchingAPI fornecida pelo [Frozen]atributo, como mostrado abaixo, mas isso requer que você desative FakeTimeProviderCustomization .

    Este teste passa:

    [Theory, MoqAutoData]
public async Task Test_TimeRelatedStuff(
    [Frozen(Matching.DirectBaseType)] FakeTimeProvider fakeTimeProvider,
    Service sut)
{

    //... Cast is no longer necessary
    //var fakeTimeProvider = timeProvider as FakeTimeProvider;
    //...
    Assert.Equal(fakeTimeProvider, sut.TimeProvider);
}

    onde eu defini Serviceassim para fins de demonstração:

    public sealed class Service(TimeProvider timeProvider)
{
    public TimeProvider TimeProvider { get; } = timeProvider;
}

    Como já sublinhado, o Matching.DirectBaseTypecritério não funciona bem com a CustomizeAPI, no sentido de que esta substitui a primeira. Para fazer o teste acima passar, desativei o FakeTimeProviderCustomization:

    public class FakeTimeProviderCustomization : ICustomization
{
    public void Customize(IFixture fixture)
    {
        //fixture.Customize<TimeProvider>
        //    (c => c.FromFactory(() => new FakeTimeProvider()));
    }
}

    Obviamente, isso torna a classe ineficaz, então você pode muito bem excluí-la. Estou mostrando o acima aqui apenas para explicar explicitamente como fazer o teste passar.

    Alternativamente , se você não quiser desativar FakeTimeProviderCustomization, você pode usar outra regra de correspondência. Se seu Serviceconstrutor se parece com Service(TimeProvider timeProvider), você pode alternativamente escrever o teste assim:

    [Theory, MoqAutoData]
public async Task Test_TimeRelatedStuff(
    [Frozen(Matching.ParameterName)] FakeTimeProvider timeProvider,
    Service sut)
{

    //... Cast is no longer necessary
    //var fakeTimeProvider = timeProvider as FakeTimeProvider;
    //...
    Assert.Equal(timeProvider, sut.TimeProvider);
}

    Observe que o nome do parâmetro de teste timeProvideré o mesmo que o nome da dependência para Service. Isso funciona mesmo se você mantiver FakeTimeProviderCustomizationactive por outros motivos.

    Obviamente, como essas ressalvas sugerem, ambas as "soluções" são frágeis, então a melhor opção pode ser reconsiderar o design geral da API e a estratégia de testes.

    • 2

relate perguntas