首先，请耐心解答我的所有问题。我以前从未使用过 TDD，但我越来越意识到我应该这样做。我已经阅读了很多帖子以及如何指导 TDD，但有些事情仍然不清楚。用于演示的大多数示例是数学计算或其他一些简单的操作。我也开始阅读 Roy Osherove 关于 TDD 的书。以下是我的一些问题:
如果您的解决方案中有一个对象，例如 Account 类，那么测试在其上设置属性有什么好处，例如帐户名称，那么您断言您设置的任何内容都是正确的。这会失败吗？
另一个例子，一个账户余额，你创建一个余额为 300 的对象，然后你断言余额实际上是 300。这怎么会失败？我会在这里测试什么？我可以看到使用不同的输入参数测试减法运算会是一个更好的测试。
我应该实际测试我的对象是什么？方法或属性？有时您还会在基础设施层中将对象作为服务。在方法的情况下，如果您有一个三层应用程序并且业务层正在为某些数据调用数据层。在那种情况下会测试什么？参数？数据对象不为空？就服务而言呢？
然后是我关于现实生活项目的问题，如果你有一个绿色项目并且你想从 TDD 开始。你先从什么开始？您是否将项目划分为功能，然后对每个功能进行 tdd，或者您实际上是任意选择然后从那里开始的。
例如，我有一个新项目，它需要登录功能。我是否从创建用户测试或帐户测试或登录测试开始。我先从哪个开始？我首先要在那堂课上测试什么？
假设我决定创建一个包含用户名和密码以及其他一些属性的 User 类。我应该首先创建测试，修复所有构建错误，运行测试以使其失败，然后再次修复以获得绿灯然后重构。那么我应该在该类上创建的第一个测试是什么？例如，是不是:
如果您断言长度大于 6，那么如何测试代码？如果小于 6，我们是否会测试是否抛出错误？
如果我重复我的问题，我很抱歉。我只是尝试开始使用 TDD，但我无法改变思维方式。谢谢，希望有人可以帮助我确定我在这里缺少什么。顺便问一下，有人知道我可以加入的有关 TDD 的任何讨论组或聊天吗？
最佳答案
看看低级 BDD。 This post by 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
然后这些将成为每个类的测试，“应该”成为测试名称。每个测试都是如何有效使用该类的示例。您不是在测试方法和属性，而是向其他人(或 future 的自己)展示该类为何有值(value)以及如何安全地更改它。
我们还在 BDD 中做一些称为“由外而内”的事情。所以从 GUI 开始(或者通常是 Controller /演示器，因为我们不经常对 GUI 进行单元测试)。
您已经知道 GUI 将如何使用 Controller 。现在写一个例子。你可能会有不止一个方面的行为，所以写更多的例子，直到 Controller 工作。 Controller 将有许多您尚未编写的协作类，因此请模拟它们 - 只需通过接口(interface)依赖注入(inject)它们即可。你可以稍后再写。
完成 Controller 后，将您在真实系统中模拟出来的下一个东西替换为真实代码，然后对其进行测试。哦，不要费心去模拟域对象(比如帐户)——这会让人头疼——但是要向它们注入(inject)任何复杂的行为，然后模拟出来。
这样，您始终可以为每个类(class)编写您希望拥有的界面 - 易于使用的界面。您正在描述该类的行为并提供一些如何使用它的示例。您正在使其安全且易于更改，并且会出现适当的设计(随意以模式、深思熟虑的常识和经验为指导)。
顺便说一句，通过登录，我倾向于找出用户想要登录的内容，然后先编写代码。稍后添加登录 - 它通常风险不大，编写后不会有太大变化，因此您甚至可能不需要对其进行单元测试。由你决定。
关于TDD:为什么、如何以及真实世界的测试驱动代码，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/7749105/