11

我们发现自己在许多测试用例中编写重复的夹具/模拟设置 - 例如这种情况：

var fixture = new Fixture().Customize(new AutoMoqCustomization());
var encodingMock = fixture.Freeze<Mock<IEncodingWrapper>>();
var httpClientMock = fixture.Freeze<Mock<IHttpWebClientWrapper>>();
var httpResponseMock = fixture.Freeze<Mock<IHttpWebResponseWrapper>>();
var httpHeaderMock = fixture.Freeze<Mock<IHttpHeaderCollectionWrapper>>();
var etag = fixture.CreateAnonymous<string>();
byte[] data = fixture.CreateAnonymous<byte[]>();
Stream stream =  new MemoryStream(data);

encodingMock.Setup(m => m.GetBytes(It.IsAny<string>())).Returns(data);
httpHeaderMock.SetupGet(m => m[It.IsAny<string>()]).Returns(etag).Verifiable();
httpClientMock.Setup(m => m.GetResponse()).Returns(httpResponseMock.Object);
httpResponseMock.Setup(m => m.StatusCode).Returns(HttpStatusCode.OK);
httpResponseMock.SetupGet(m => m.Headers).Returns(httpHeaderMock.Object);
httpResponseMock.Setup(m => m.GetResponseStream()).Returns(stream);

根据测试应该是自包含且从头到尾可读的想法，我们不使用神奇的设置/拆卸方法。

我们能以任何方式（AutoFixture 自定义、辅助方法）减少这些测试的“繁重工作”吗？

4

3 回答 3

15

越来越多的面向对象软件(GOOS) 提出了一个很好的建议：如果一个测试很难编写，它是关于被测系统 (SUT) 的 API 的反馈。考虑重新设计 SUT。在这个特定示例中，看起来 SUT 至少有四个依赖项，这可能表明违反了单一责任原则。是否可以重构为 Facade Services？

来自 GOOS 的另一个很好的建议是

在上面的示例中，您似乎需要为真正属于查询的方法进行大量 Moq 设置。这也表明测试气味。有没有违反得墨忒耳法则的地方？是否有可能切断方法链？

于 2012-05-08T08:10:36.263 回答
13

您可以创建一个复合定制，该定制将使用所有包含的定制来定制灯具。

public class HttpMocksCustomization : CompositeCustomization
{
    public HttpMocksCustomization()
        : base(
            new AutoMoqCustomization(),
            new HttpWebClientWrapperMockCustomization(),
            new HttpWebResponseWrapperMockCustomization()
            // ...
            )
    {
    }
}

每个自定义可以定义如下：

public class HttpWebClientWrapperMockCustomization : ICustomization
{
    public void Customize(IFixture fixture)
    {
        var mock = new Mock<IHttpWebClientWrapper>();
        mock.Setup(m => m.GetResponse()).Returns(httpResponseMock.Object);

        fixture.Inject(mock);
    }
}

public class HttpWebResponseWrapperMockCustomization : ICustomization
{
    public void Customize(IFixture fixture)
    {
        var mock = new Mock<IHttpWebResponseWrapper>();
        mock.Setup(m => m.StatusCode).Returns(HttpStatusCode.OK);

        fixture.Inject(mock);
    }
}

// The rest of the Customizations.

然后在测试方法中你可以这样做：

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

这样，当您请求 Mock 实例时，您不必重复设置步骤。我们之前自定义的那个会被返回：

var httpClientMock = fixture.Freeze<Mock<IHttpWebClientWrapper>>();

但是，如果您使用 xUnit.net，事情可以进一步简化。

您可以创建一个 AutoDataAttribute 派生类型，以提供由 AutoFixture 生成的自动生成的数据样本，作为 xUnit.net 的 Theory 属性的扩展：

public class AutoHttpMocksDataAttribute : AutoDataAttribute
{
    public AutoHttpMocksDataAttribute()
        : base(new Fixture().Customize(new HttpMocksCustomization()))
    {
    }
}

然后，在您的测试方法中，您可以将 Mocks 作为参数传递：

[Theory, AutoHttpMocksData]
public void MyTestMethod([Freeze]Mock<IHttpWebClientWrapper> httpClientMock, [Freeze]Mock<IHttpWebResponseWrapper> httpResponseMock)
{
    // ...
}
于 2012-05-08T07:13:42.883 回答
4

如果您的所有测试都使用此代码，则应将其放在设置/拆卸方法中。如果您的设置/拆卸方法有些复杂，那没关系，只要您的所有单元测试都依赖于它。这肯定比在每次测试中复制所有复杂的东西要好。当我阅读测试时，我知道 setup 和 teardown 是每个测试的一部分，所以我认为你也不会失去任何可读性。要避免的事情是在设置中包含并非每个测试都需要的东西。这会造成令人困惑的情况，即您设置的方法不能很好地匹配所有测试。理想情况下，您的设置方法应 100% 应用于每个测试。

如果您的所有测试中都没有使用共享代码，请将共享代码提取到辅助函数中。编写好的测试代码就像编写任何其他好的代码一样，并且适用相同的原则。

于 2012-05-08T06:22:03.727 回答