mocking - ¿Esta prueba hace un uso adecuado de AutoFixture y Moq?

Question

¿Esta prueba hace un uso adecuado de AutoFixture y Moq? ¿Está escrito lo más concisamente posible? La prueba falla, como se esperaba, y pasa después de escribir la implementación correcta.

[Fact]
public void CustomerPropertyIsCorrect()
{
var fixture = new AutoMoqFixture();
var expected = fixture.Create<CardHolderCustomer>();
var builderMock = fixture
.Freeze<Mock<ICustomerAdapter>>()
.Setup(x => x.BuildCustomer()).Returns(expected);
var sut = fixture.Create<CardHolderViewModel>();
var actual = sut.Customer;
Assert.Equal(expected, actual);
}

Answer 1

¡Se ve bien! Sin embargo, también puede usarla declarativamente con la extensión xUnit.net.

Suponiendo que los tipos utilizados en la prueba se definen como:

public class CardHolderCustomer
{
}
public interface ICustomerAdapter
{
CardHolderCustomer BuildCustomer();
}
public class CardHolderViewModel
{
private readonly ICustomerAdapter adapter;
public CardHolderViewModel(ICustomerAdapter adapter)
{
if (adapter == null)
throw new ArgumentNullException("adapter");
this.adapter = adapter;
}
public CardHolderCustomer Customer
{
get
{
return this.adapter.BuildCustomer();
}
}
}

La prueba original se puede escribir como :

[Theory, DomainTestConventions]
public void CustomerPropertyIsCorrect2(
CardHolderCustomer expected,
[Frozen]Mock<ICustomerAdapter> builderStub,
CardHolderViewModel sut)
{
builderStub
.Setup(x => x.BuildCustomer())
.Returns(expected);
var actual = sut.Customer;
Assert.Equal(expected, actual);
}

El DomainTestConventionsAttribute se define como:

internal class DomainTestConventionsAttribute : AutoDataAttribute
{
internal DomainTestConventionsAttribute()
:base(new Fixture().Customize(new DomainTestConventions()))
{
}
}

DomainTestConventions se define como:

internal class DomainTestConventions : CompositeCustomization
{
internal DomainTestConventions()
:base(new AutoMoqCustomization())
{
}
}

Tenga en cuenta que DomainTestConventions deriva de CompositeCustomization que básicamente significa que puede crear más personalizaciones y agregarlas como parámetros al constructor base.

También puede leer:

• El orden de las personalizaciones de AutoFixture importa
• Teorías de AutoData con AutoFixture
• Mantenga las pruebas de su unidad SECAS con personalizaciones de AutoFixture
• AutoFixture, xUnit.net y Auto Mocking

Espero que ayude.

Answer 2

Creo que esto es conciso y legible. Pero cuestiono el valor de este tipo de prueba.

Su prueba se llama CustomerPropertyIsCorrect , así que supongo que esto es lo que quiere probar. Dado que usted indica al método BuildCustomer de su ICustomerAdapter que devuelva la instancia congelada creada anteriormente, y dado que el código del modelo de vista usará este código cuando se ejecuta en xUnit, sí, el objeto congelado se devolverá.

Ahora, no estoy todo-en el campo de TDD (todavía) así que este puede ser solo yo, no "obteniendo" TDD. Pero, por lo que puedo ver, esta prueba verificará que el modelo de vista tenga alguna instancia de CardHolderCustomer en su propiedad de Cliente, pero no necesariamente la "correcta". ¿Dónde está el valor en eso?