c# - 单元测试和验证逻辑

Question

我目前正在为包含验证例程的业务逻辑类编写一些单元测试。例如:

public User CreateUser(string username, string password, UserDetails details)
{
    ValidateUserDetails(details);
    ValidateUsername(username);
    ValidatePassword(password);

    // create and return user
}

我的测试夹具是否应该包含对 Validate* 方法中可能发生的每个可能的验证错误的测试，还是最好将其留给一组单独的测试？或者验证逻辑应该以某种方式重构？

我的理由是，如果我决定测试 CreateUser 中可能发生的所有验证错误，测试装置将变得非常臃肿。而且大多数验证方法都来自不止一个地方......

在这种情况下有什么好的模式或建议吗？

Answer 1

每个测试都应该只因一个原因而失败，并且只有一个测试应该因此而失败。

这对编写一组可维护的单元测试有很大帮助。

我会分别为 ValidateUserDetails、ValidateUsername 和 ValidateUserPassword 编写几个测试。然后您只需要测试 CreateUser 是否调用了这些函数。

---

重新阅读你的问题；看来我有点误解了。

您可能对 J.P Boodhoo 关于他的行为驱动设计风格的文章感兴趣。 http://blog.developwithpassion.com/2008/12/22/how-im-currently-writing-my-bdd-style-tests-part-2/

BDD 正在成为一个非常重载的术语，每个人都有不同的定义和不同的工具来实现它。据我所知，JP Boodhoo 正在做的是根据关注点而不是类别来拆分测试装置。

例如，您可以创建单独的装置来测试用户详细信息的验证、用户名的验证、密码的验证和创建用户。 BDD 的想法是，通过以正确的方式命名测试夹具和测试，您可以通过打印出测试夹具名称和测试名称来创建几乎读起来像文档的东西。按关注点而不是按类别对测试进行分组的另一个优点是，您可能只需要为每个固定装置设置和拆卸例程。

虽然我自己对此没有太多经验。

如果您有兴趣阅读更多内容，JP Boodhoo 在他的博客上发布了很多相关内容(见上面的链接)，或者您也可以收听 Scott Bellware 的 dot net rocks 插曲，他在其中谈到了类似的方法分组和命名测试 http://www.dotnetrocks.com/default.aspx?showNum=406

我希望这是您正在寻找的更多内容。