我们发现自己在许多测试用例中编写重复的夹具/模拟设置 - 就像这个案例:
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 自定义、辅助方法)减少这些测试的“繁重工作”？
最佳答案
来自 Growing Object-Oriented Software (GOOS) 提出了一条很好的建议:如果很难编写测试，那就是对被测系统 (SUT) 的 API 的反馈。考虑重新设计 SUT。在此特定示例中，SUT 似乎至少有四个依赖项，这可能表明违反了 Single Responsibility Principle .是否可以refactor to Facade Services ？
GOOS 的另一个重要建议是
在上面的示例中，您似乎需要为真正是查询的方法执行大量的 Moq 设置。这也表明测试气味。有没有Law of Demeter某处违规？是否可以切断方法链？
关于c# - 单元测试中的重复代码，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/10493510/