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

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

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

    // create and return user
}

如果我的测试夹具包含可能在Validate *方法中发生的每个可能的验证错误的测试,还是最好将其留下来进行单独的测试？或者验证逻辑应该以某种方式重构？

我的推理是,如果我决定测试createuser中可能发生的所有验证错误,测试夹具将变得相当.肿.大多数验证方法都是从多个地方使用的…

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

解决方法

每次测试都只能由于一个原因而失败,因此只有一个测试失败.

这有助于编写可维护的单元测试集.

我会为ValidateUserDetails,ValidateUsername和ValidateUserPassword编写几个测试.那么你只需要测试createuser 调用这些函数.

重读你的问题似乎我误解了一些事情.

你可能对J.B Boodhoo在他的行为驱动设计风格上写的感兴趣.
http://blog.developwithpassion.com/2008/12/22/how-im-currently-writing-my-bdd-style-tests-part-2/

BDD正在成为一个非常超负荷的术语,每个人都有不同的定义和不同的工具来做到这一点.据我所知,JP Boodhoo正在做的是根据关注分类测试夹具而不是类.

例如,您可以创建单独的夹具来测试用户详细信息的验证,用户名验证,密码验证和创建用户. BDD的想法是,通过命名testfixtures和测试正确的方式,您可以通过打印出testfixture名称和测试名称来创建几乎看起来像文档的东西.通过关注而不是按类分组测试的另一个优点是,您可能只需要每个灯具的一个设置和拆卸程序.

我本人没有很多经验.

如果您有兴趣阅读更多内容,JP Boodhoo在他的博客上发表了很多关于这一点的信息(参见上面的链接),或者也可以用Scott Bellware来听点网络岩石情节,他谈论类似的分组和命名方法测试http://www.dotnetrocks.com/default.aspx?showNum=406

我希望这更多是你要找的.

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

解决方法

相关文章