4

好的，正如我在另一个问题中回答的AutoMoq那样，默认情况下不使用 AutoFixture。这很好，通过设置和设置很容易解决ReturnsUsingFixture。

但这可以通过自动夹具数据理论进行设置吗？

所以我们有一个自定义的 AutoDataAttribute，我将调用它[MyAutoData]。在那里，我们调用并设置了一堆自定义项，例如AutoConfiguredMoqCustomization，将其配置为生成 webapi 控制器，并注册许多自定义生成器。所以我们已经能够将几乎所有的样板配置提取到一些基本的配置文件中。我们甚至MyAutoData为系统测试设置了属性，所以如果您要求，比如说，Id<Account>它会使用实际的 webapi 调用创建一个新帐户并返回一个有效的帐户 ID。

但是您如何处理设置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)？还是我只是在想这个问题都错了？

4

2 回答 2

4

该方法允许您在创建样本后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);
    }
}
于 2015-10-23T21:36:54.187 回答
4

FWIW，我已经认为这AutoConfiguredMoqCustomization对我的口味来说太含蓄了。然而，AutoFixture 是一个社区项目，其他人发现它足够有用，可以实施它。

我认为设计 AutoConfiguredMoqCustomization上没有任何理由不设置通用方法。我认为简单的原因是它很难做到。换句话说，不是 AutoFixture不会为您做到这一点，而是它不能。

说了这么多，本着GOOS的精神，我认为你应该听听你的测试。如果测试难以编写，通常意味着SUT难以使用。这应该首先引发对 SUT 的反思，而不是测试。

您能否设计 SUT 以使您不需要此 AutoFixture 功能？

于 2015-10-24T12:29:16.500 回答