首先，请耐心等待我的所有问题。我之前从未使用过TDD，但越来越多的人意识到我应该这样做。我已经阅读了很多帖子以及如何指导TDD，但有些事情仍然不清楚。用于演示的大多数示例都是数学计算或其他一些简单的操作。我也开始阅读Roy Osherove关于TDD的书。以下是我的一些问题：
如果您的解决方案中有一个对象，例如Account类，那么测试在其上设置属性的好处是什么，例如帐户名，那么您断言您设置的内容是正确的。这会失败吗？
另一个例子，一个账户余额，你用余额300创建一个对象然后断言余额实际上是300.那怎么会失败？我在这里测试什么？我可以看到用不同的输入参数测试减法操作将是一个更好的测试。
我应该为实际测试对象做些什么？方法或属性？有时您还在基础架构层中将对象作为服务。对于方法，如果您有一个三层应用程序，并且业务层正在为某些数据调用数据层。在那种情况下测试了什么？参数？数据对象不为空？在服务的情况下怎么样？
接下来关于真实生活项目的问题，如果你有一个绿色项目，你想用TDD开始它。你先从什么开始？你是否将你的项目划分为特征然后每个特征，或者你实际上是随意挑选的，然后你从那里开始。
例如，我有一个新项目，它需要一个登录功能。我是从创建用户测试或帐户测试或登录测试开始的。我先从哪一个开始？我先在该课上测试什么？
假设我决定创建一个具有用户名和密码以及其他一些属性的User类。我应该首先创建测试，修复所有构建错误，运行测试以使其失败，然后再次修复以获得绿灯然后重构。那么我应该在该课程上创建的第一批测试是什么？例如，是吗：
如果断言长度大于6，那么测试代码的方式如何？如果它小于6，我们测试我们抛出错误吗？
如果我对我的问题重复，我很抱歉。我只是想开始使用TDD并且我无法改变心态。谢谢你，希望有人可以帮我确定我在这里缺少什么。顺便问一下，有没有人知道我可以参加任何有关TDD的讨论组或聊天？
答案 0 :(得分：7)
看看低级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
然后这些将成为每个类的测试，“should”将成为测试名称。每个测试都是如何有价值地使用该类的示例。您没有测试方法和属性，而是向其他人（或您未来的自己）展示为什么该类有价值以及如何安全地更改它。
我们在BDD中也做了一些名为“从外到内”的事情。所以从GUI开始（或者通常是控制器/演示者，因为我们通常不对GUI进行单元测试）。
您已经知道GUI将如何使用控制器。现在写一个例子。您可能有多个行为方面，因此请在控制器工作之前编写更多示例。控制器将有许多尚未编写的协作类，因此请将其模拟出来 - 只需依赖通过接口注入它们。你可以稍后再写。
当你完成控制器后，用实际代码替换你在真实系统中模拟过的下一件事，并测试它。哦，不要打扰嘲笑域名对象（比如账号） - 这将是一个痛苦的问题 - 但确实会向他们注入任何复杂的行为并反而嘲笑它。
这样，您总是为每个班级编写您希望拥有的界面 - 易于使用的界面。您正在描述该类的行为并提供一些如何使用它的示例。你正在使它安全且易于改变，并且会出现适当的设计（随意引导模式，深思熟虑的常识和经验）。
BTW，使用Login，我倾向于找出用户想要登录 for 的内容，然后先编写代码。稍后添加登录 - 它通常风险不大，一旦写入就不会有太大变化，因此您甚至可能不需要进行单元测试。由你决定。
答案 1 :(得分：3)
测试直到恐惧被无聊取代。属性访问器和构造器是高成本，有利于编写测试。我通常间接测试它们作为其他（更高）测试的一部分。
对于一个新项目，我建议您查看ATDD。找到您要首先选择的用户故事（基于用户值）。编写一个应在用户故事完成时通过的验收测试。现在深入研究使用TDD传递AT所需的类型。验收测试将告诉您哪些对象和需要哪些行为。然后使用TDD一次实现一个。当您的所有测试（包括您的acc。测试）通过时 - 您将获取下一个用户故事并重复。
假设您选择“创建用户”作为您的第一个故事。然后你写下应该如何工作的例子。将它们变成自动验收测试。 创建有效用户 - ＆gt;应该创建帐户 创建无效用户（显示无效内容的差异组合） - ＆gt;不应创建帐户，向用户显示有用的错误
AccountsVM.CreateUser（用户名，密码） AccountsVM.HasUser（用户名） AccountsVM.ErrorMessage
测试表明您需要上述内容。然后你试试它们吧。
答案 2 :(得分：2)
不要测试太简单的东西。
getter和setter太简单了，所以说，代码非常简单，不会发生错误。
您测试公共方法并断言响应符合预期。如果方法返回void，则必须测试“附带后果”（有时候并不容易，例如测试发送的电子邮件）。当发生这种情况时，你可以使用模拟来测试不是响应，而是测试方法是如何执行的（如果被测试类称为他所需的方式，你可以询问模拟器）
我开始做Katas来学习基础知识：JUnit和TestNG;然后是Harmcrest;然后阅读EasyMock或Mockito文档。
在github或这里寻找katas http://codekata.pragprog.com http://codingdojo.org/
第一次测试应该是最简单的！也许只会迫使你创建CUT（被测试的类）
但是再次尝试katas！