我建议不要担心 Web 服务端点,而是关注系统的行为。为了便于讨论,我将抛开所有技术术语,谈谈我认为您要解决的核心业务问题:创建产品目录。
为了做到这一点,首先要考虑产品目录的作用,而不是关于如何做的技术细节。将其用作测试的起点。
public class ProductCatalogTest
{
[Test]
public void allowsNewProductsToBeAdded() {}
[Test]
public void allowsUpdatesToExistingProducts() {}
[Test]
public void allowsFindingSpecificProductsUsingSku () {}
}
我不会在这里详细介绍如何实现测试和生产代码,但这是一个起点。一旦完成了ProductCatalog
生产类,您就可以将注意力转向技术细节,例如制作 Web 服务和编组 JSON。
我不是 .NET 人,所以这主要是伪代码,但它可能最终看起来像这样。
public class ProductCatalogServiceTest
{
[Test]
public void acceptsSkuAsParameterOnGetRequest()
{
var mockCatalog = new MockProductCatalog(); // Hand rolled mock here.
var catalogService = new ProductCatalogService(mockCatalog);
catalogService.find("some-sku-from-url")
mockCatalog.assertFindWasCalledWith("some-sku-from-url");
}
[Test]
public void returnsJsonFromGetRequest()
{
var mockCatalog = new MockProductCatalog(); // Hand rolled mock here.
mockCatalog.findShouldReturn(new Product("some-sku-from-url"));
var mockResponse = new MockHttpResponse(); // Hand rolled mock here.
var catalogService = new ProductCatalogService(mockCatalog, mockResponse);
catalogService.find("some-sku-from-url")
mockCatalog.assertWriteWasCalledWith("{ 'sku': 'some-sku-from-url' }");
}
}
您现在已经进行了端到端的测试,并测试了整个过程。我个人会测试驱动包含在其中的业务逻辑,ProductCatalog
并且可能会跳过测试编组,因为无论如何它都可能由框架完成,并且只需很少的代码即可将控制器绑定到产品目录中。你的旅费可能会改变。
最后,在测试驱动目录时,我希望代码被拆分为多个类并在那里进行模拟,因此它们将进行单元测试,而不是大型集成测试。同样,这是另一天的话题。
希望有帮助!
布兰登