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

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

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();
}

所以我对这个进行单元测试，测试空名称和空父项将失败。为了解决这个问题，我必须重构Insert方法，如下所示：

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测试单元中测试这类内容。除了验证相关任务外，我应该在我的业务逻辑方法中测试什么？如果没有什么东西需要进行单元测试，为什么大家都说“所有层都要进行单元测试”之类的话，我在网上找到了很多类似的东西？

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

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

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

更容易弄清楚要测试什么。您可以通过简单的代码阅读（或者更好的是，通过技术规范）了解失败的情况

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

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

---

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

谢谢你的回答。您的观点都是正确的，但我选择了UI进行验证，因为：第一，它可以有客户端通知，第二，它将提供更快的响应，这意味着如果出现问题，页面加载会更快。另一种方法是将验证分为UI和bll，UI只验证简单的逻辑，bll验证复杂的规则，但我发现，对于简单的事情来说，单一的责任和太多的复杂性是不利的。@jim，在我当前的项目中，我们有一个远程后端执行业务规则。为了用户和企业的最大利益，我们在前端尽可能地进行验证，以节省网络带宽和往返时间。我们只验证我所说的硬规则：例如，最小值必须始终小于或等于最大值，未来事件必须有未来日期，等等。业务规则不会改变这类事情。但是，后端必须再次验证所有内容，因为它不能依赖于我的实现。由于您有一个远程后端，我看不到任何其他适用于您的项目的解决方案，但是单一责任如何？您的方法是否违反了层级别的原则？@Jim您应该始终验证UI，以保护您的应用程序不受用户发送坏数据的影响，并提供更好的用户体验。您始终需要在业务层进行验证，以保护您的应用程序免受黑客的攻击，黑客可能篡改了请求，并且能够绕过在表示层设置的验证，并验证复杂的业务规则，这是该层的目的之一。如果您的业务类调用了一个验证类来履行职责，那么您就不会违反单一责任原则。非常感谢sergio的评论。现在，每个业务类都有不同的验证。所以对于每个bll类，我需要一个不同的验证类？还是有别的办法？