Question

在阅读Pro ASP.NET MVC Framework 的前7章后 - 我会说非常推荐的读物。在我的阅读过程中，作者 - Steve Sanderson对一些TDD实践进行了大量的探讨。现在我的问题是：
史蒂夫曾经对控制器本身进行单元测试，这本书的一个例子是：

[Test]
    public void List_Includes_All_Products_When_Category_IsNull() {
        //Arrange: 
        IProductsRepository repository = MockProductsRepository(
            new Product { Name = "First Product", Category= "Cat11"}, 
            new Product { Name = "SecondProduct", Category = "Cat22" } 
        );
        ProductsController controller = new ProductsController(repository);
        controller.PageSize = 10;

        //Act: 
        var result = controller.List(null, 1);

        //Assert: 
        Assert.IsNotNull(result, "Didn't render view!");
        var model = controller.ViewData.Model as IList<Product>;
        Assert.AreEqual(2, model.Count, "Got wrong number of products!");
        Assert.AreEqual(model[0].Name, "First Product", "Not the expected first item.");
        Assert.AreEqual(model[1].Name, "SecondProduct", "Not the expected second item.");           
    }

我理解为什么史蒂夫正在测试这个，显然他需要根据他设置的ViewData标志来检查他的逻辑，这就是他需要调用List控制器动作的原因，我的问题是，这还够吗？我的意思是，不应该先测试他的Model对象吗？ Steve正在使用LINQ2SQL作为他的ORM工具，他几乎没有使用LINQ功能以外的任何东西，我的意思是这个例子只选择数据，并通过调用LINQ内置方法进行更新;没有业务验证。在我的真实应用程序中，有很多应该进行的业务验证，是否足够（或者更容易）让我在控制器级别开始测试，忽略我的Model类（因为我不认为它是一个好主意）？
等待你的想法Gus！

Answer 1

我认为除了控制器测试之外，您还希望对业务逻辑进行单独测试。

我正像史蒂夫一样安排我的控制器测试。基本上，根据条件，我的控制器是否包含预期的查看数据？而已。没有断言数据的内部细节或任何其他业务逻辑 - 包含在单独测试中的东西。

按照你的例子，我会在你的控制器测试中保留它，并且假设你有一些防止负价格的业务逻辑，你可能会对“Product_discount_does_not_result_in_negative_price（）”之类的东西进行单独的测试Web上下文和控制器。假设你的产品类中有一条规则使得它的价格最低为1美元，即使某些所谓的折扣实际上超过了实际的默认价格:(一个可怕的例子，抱歉！）

[Test]
Product_discount_does_not_result_in_negative_price() {
    Product p = new Product {price = 5, discount = 10};
    Assert.IsTrue(p.price == 1); //expecting the price Get() to return 1 in this case
}

我认为如果你在控制器级别保持测试会遇到的问题，它需要在你准备好之前创建测试并实现控制器。

测试控制器还是商业模式？

1 个答案: