asp.net - 为什么我要在 MVP 中对业务层进行单元测试

Question

我在业务逻辑层创建了以下示例方法。我的数据库不允许名称和父列为空值:

public void Insert(string catName, long catParent)
{
    EntityContext con = new EntityContext();
    Category cat = new Category();
    cat.Name = catName;
    cat.Parent = catParent;
    con.Category.AddObject(cat);
    con.SaveChanges();
}

所以我对此进行单元测试并测试空名称和空父项将失败。为了解决这个问题，我必须按如下方式重构插入方法:

public void Insert(string catName, long catParent)
{
    //added to pass the test
    if(string.IsNullOrEmpty(catName)) throw new InvalidOperationException("wrong action. name is empty.");
    long parent;
    if(long.TryParse(catParent, out parent) == false) throw new InvalidOperationException("wrong action. parent didn't parsed.");
    //real bussiness logic
    EntityContext con = new EntityContext();
    Category cat = new Category();
    cat.Name = catName;
    cat.Parent = parent;
    con.Category.AddObject(cat);
    con.SaveChanges();
}

我的整个业务层都是对数据库的简单调用。所以现在我再次验证数据!我已经计划在 UI 中进行验证并在 UI 测试单元中测试此类内容。除了验证相关任务之外，我应该在我的业务逻辑方法中测试什么？如果没有什么要进行单元测试的，为什么每个人都说“对所有层进行单元测试”以及我在网上经常找到的类似内容？

Answer 1

测试中涉及的技术是将程序分解成更小的部分(更小的组件甚至类)并测试这些小部分的技术。当您将这些部分组装在一起时，您会进行不太全面的测试——较小的部分已经被证明可以工作——直到你有一个功能性的、经过测试的程序，然后你将它提供给用户进行“用户测试”。

最好测试较小的零件，因为:

1. 编写测试更简单。您将需要更少的数据，您只需设置一个对象，您必须注入(inject)更少的依赖项。

2. 更容易找出要测试的内容。您通过简单阅读代码(或者，更好的是，通过技术规范)了解失败条件。

现在，您如何保证您的业务层(尽管很简单)得到正确实现？如果写得不好，即使是简单的数据库插入也可能失败。此外，您如何保护自己免受变化的影响？没错，代码是有效的，但如果数据库更改或有人更新业务逻辑，将来会发生什么。

但是，这很重要，您实际上不需要测试所有内容。使用您的直觉(也称为经验)了解什么需要测试，什么不需要。如果您的方法足够简单，只需确保正确测试客户端代码即可。

最后，您说过所有验证都将在 UI 中进行。业务层应该能够验证数据以增加应用程序的重用。如果做不到这一点，将来无论您或任何人对您的代码进行更改，都可能会创建新的 UI 而忘记添加所需的验证。