如果您的解决方案中有一个对象,例如一个Account类,那么测试设置一个属性的好处(例如一个帐户名称)有什么好处,那么你断言无论你设置什么都是正确的.这会不会失败？
另一个例子,帐户余额,你创建一个平衡300的对象,那么你断言余额实际上是300.怎么会失败？我在这里测试什么？我可以看到测试一个减法操作与不同的输入参数会更好的测试.
我该怎么实际测试我的对象？方法或属性？有时您也可以在基础设施层中将对象作为服务.在方法的情况下,如果您有三层应用程序,并且业务层正在调用某些数据的数据层.在这种情况下被测试了什么？的参数？数据对象不为null？在服务的情况下呢？
接下来我关于现实生活中的问题,如果你有一个绿色的项目,并且想要开始使用TDD.你从头开始是什么？你把你的项目划分成一个特征,然后把它们分成几个,或者你实际上是任意选择你从那里去的.
例如,我有一个新项目,它需要一个登录功能.我开始创建用户测试或帐户测试或登录测试.我先从哪一个开始？我先在班上测试什么？
假设我决定创建一个具有用户名和密码以及一些其他属性的User类.我应该首先创建测试,修复所有构建错误,运行测试失败,然后再次修复以获得绿灯,然后重构.那么我应该在该类上创建的第一个测试是什么？例如,是吗？
> Username_Length_Greater_Than_6
> Username_Length_Less_Than_12
>密码_复制
如果你断言长度大于6,那么测试代码呢？我们测试如果小于6则抛出错误？
我很抱歉,如果我重复我的问题.我只是想开始使用TDD,而且我不能有一个心态的改变.谢谢,希望有人可以帮助我确定我在这里失踪了什么.顺便说一句,有谁知道有关TDD的任何讨论组或聊天,我可以加入？
不要测试属性,而是考虑您要查找的行为.例如：
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
这些将成为每个类的测试,“应该”成为测试名称.每个测试都是如何有价值地使用课程的例子.您不是测试方法和属性,而是显示别人(或未来的自我),为什么这个类是有价值的,以及如何安全地改变它.
我们也在BDD中做了一些叫做“外在”的东西.所以从GUI开始(或通常是控制器/演示者,因为我们不经常单元测试GUI).
您已经知道GUI将如何使用控制器.现在写一个例子.你可能会有不止一个方面的行为,所以写更多的例子,直到控制器工作.控制器将有一些你还没有编写的协作类,所以嘲笑这些 – 只是依赖通过一个接口注入它们.你可以稍后再写.
完成控制器后,用真实的代码替换您在实际系统中嘲笑的下一件事情,然后测试驱动.哦,不要打扰域名对象(如帐号) – 这将是一个痛苦的脖子 – 但是注入任何复杂的行为,并嘲笑它.
这样,你总是为每个课程编写你希望拥有的界面 – 一些易于使用的界面.您正在描述该类的行为,并提供一些如何使用它的示例.您正在使其安全,易于更改,并将出现适当的设计(随时可以通过图案,周到的常识和经验来指导).
BTW,通过登录,我倾向于找出用户想要登录的内容,然后再编码.稍后添加登录 – 它通常不是很危险的,一旦写入就不会改变太多,所以你可能甚至不需要对它进行单元测试.由你决定.
