首先,请耐心等待我的所有问题.我之前从未使用过TDD,但越来越多的人意识到我应该这样做.我已经阅读了很多帖子以及如何指导TDD,但有些事情仍然不清楚.用于演示的大多数示例都是数学计算或其他一些简单的操作.我也开始阅读Roy Osherove关于TDD的书.以下是我的一些问题:
如果您的解决方案中有一个对象,例如Account类,那么测试在其上设置属性的好处是什么,例如帐户名,那么您断言您设置的内容是正确的.这会失败吗？
另一个例子,一个账户余额,你用余额300创建一个对象,然后你断言余额实际上是300.那怎么会失败？我在这里测试什么？我可以看到用不同的输入参数测试减法操作将是一个更好的测试.
我应该为实际测试对象做什么？方法或属性？有时您还在基础架构层中将对象作为服务.对于方法,如果您有一个三层应用程序,并且业务层正在为某些数据调用数据层.在那种情况下测试了什么？参数？数据对象不为空？在服务的情况下呢？
接下来关于真实生活项目的问题,如果你有一个绿色项目,你想用TDD开始它.你先从什么开始？你是否将你的项目划分为特征然后每个特征,或者你实际上是随意挑选的,然后你从那里开始.
例如,我有一个新项目,它需要一个登录功能.我是从创建用户测试或帐户测试或登录测试开始的.我先从哪一个开始？我先在该课上测试什么？
假设我决定创建一个具有用户名和密码以及其他一些属性的User类.我应该首先创建测试,修复所有构建错误,运行测试以使其失败,然后再次修复以获得绿灯然后重构.那么我应该在该课程上创建的第一批测试是什么？例如,它是:
如果断言长度大于6,那么测试代码的方式如何呢？如果它小于6,我们测试我们抛出错误吗？
如果我对我的问题重复,我很抱歉.我只是想开始使用TDD并且我无法改变心态.谢谢你,希望有人可以帮我确定我在这里缺少什么.顺便问一下,有没有人知道我可以加入任何关于TDD的讨论组或聊天？
看看低级BDD.Dan North的这篇文章很好地介绍了它.
而不是测试属性,考虑您正在寻找的行为.例如:
Account Behavior:
should allow a user to choose the account name
should allow funds to be added to the account
User Registration Behavior:
should ensure that all usernames are between 6 and 12 characters
should ask the password checker if the password is complex enough <-- you'd use a mock here
然后这些将成为每个类的测试,"should"将成为测试名称.每个测试都是如何有价值地使用该类的示例.您没有测试方法和属性,而是向其他人(或您未来的自我)展示为什么该类有价值以及如何安全地更改它.
我们在BDD中也做了一些名为"从外到内"的事情.所以从GUI开始(或者通常是控制器/演示者,因为我们通常不对GUI进行单元测试).
您已经知道GUI将如何使用控制器.现在写一个例子.您可能有多个行为方面,因此请在控制器工作之前编写更多示例.控制器将有许多尚未编写的协作类,因此请将其模拟出来 - 只需依赖通过接口注入它们.你可以稍后再写.
当你完成控制器后,用实际代码替换你在真实系统中模拟过的下一件事,并测试它.哦,不要打扰嘲弄域名对象(比如账号) - 这将是一个痛苦的问题 - 但是确实会将任何复杂的行为注入其中并反而嘲笑它.
这样,您总是为每个班级编写您希望拥有的界面 - 易于使用的界面.您正在描述该类的行为并提供一些如何使用它的示例.您正在使其安全且易于更改,并且将出现适当的设计(随意引导模式,深思熟虑的常识和经验).
顺便说一下,使用Login,我倾向于找出用户想要登录的内容,然后先编写代码.稍后添加登录 - 它通常风险不大,一旦写入就不会有太大变化,因此您甚至可能不需要进行单元测试.由你决定.
| 归档时间： |
|
| 查看次数： |
2204 次 |
| 最近记录： |