为什么我要在 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. 编写测试更简单。你需要更少的数据，你只需要设置一个对象，你必须注入更少的依赖。

2. 更容易确定要测试的内容。您可以通过简单阅读代码（或者更好的是，通过技术规范）了解失败的条件。

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

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

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