我正在与一群专业人士合作举办一个活动，以帮助有兴趣但没有经验(新手)的人学习TDD的实践。

我们正在尝试建立实验室，讲习班等，并且我正在考虑我们需要传授给这些个人的最大的东西，以帮助他们成功地实现TDD。

我们会说我们应该优先学习吗？教学TDD的哪个方面最重要。如果我们必须做两件事，那没关系，我不会让我们陷入"单身"的问题:)

解决方案

不要跳过该过程中的步骤。进入TDD的初始阶段需要花费更长的时间，但是一旦安装到位，整个SDLC就会更快，更安全。

红色绿色重构->做到这一点。

以我的经验，使用TDD可使我和我的团队毫不留情地重构代码，而不必担心会破坏某些意外的地方。

所以我想我对TDD最重要的方面是覆盖率，因为良好的覆盖率使我有信心在代码库中发现任何可以使用它的地方进行重构。

仅仅因为测试通过，并不意味着代码是正确的。

除此之外，我想说的是在设计中考虑进行测试很重要。如果代码很难在不熟悉被测单元内部实现的情况下进行测试，则可能需要重新考虑设计。否则，由于测试可能必须使用代码进行更改，因此重构变得更容易产生风险。

我建议"保持耐心"。一开始感觉很奇怪。对我来说，这可能是三个项目，然后才开始变得自然。

当截止日期越来越近时，应对放弃TDD的压力。这是我在帮助TDD人员和团队方面遇到的最大问题之一。他们很难表达删除功能而不是对更高管理层进行测试的重要性和价值。

这是关于设计的。这与测试无关。

继续进行。

确保测试仅覆盖很小的范围，并且如PhlipCPP所说："执行通过测试所需的最小编辑。"

即便如此，TDD还有很多东西，因此我们仍然必须确保我们不会错过任何东西。

强调各种测试。黑盒测试和白盒测试都非常重要，并且具有不同的用途。没有白盒测试来验证正确性，因为它无法测试整个系统。它可以使代码闻起来甚至更臭，因此提供了更好的重构方向。黑盒测试可以测试正确性。每个功能都应经过黑盒测试。

另外，要强调测试范围的差异。由于组合和可重复性问题，不可能对应用程序中的每个代码路径进行黑盒测试。我的规则是，一项功能只有在经过黑盒测试后才能完成。我们应该帮助学生弄清楚自己的规则。但是，白盒测试不应具有外部类依赖性。因此，每个类别的每一行都应该经过白盒测试。

我同意乔恩在回答中所说的话，但是我认为一个重要的推论是，可测试性并不能决定"好的设计"，而只是可表明设计达到目标的指标。

我不知道这是否算是最重要的事情，但是当我第一次使用TDD探索时，这花费了我一些时间。

在编写测试之前，请不要在脑海中写下代码。

当我第一次开始进行TDD时，我"知道"设计应该是什么。我"知道"我要编写的代码。所以我写了一个测试，让我可以写那段代码。

当我这样做时，因为我是先编写代码，所以我并没有真正做过TDD(即使代码只是在我的脑海:-)

我花了一些时间(和一些聪明的人戳了一下)才意识到我们需要专注于测试。针对我们想要的行为编写测试，然后编写通过测试所需的最少代码，然后让设计通过重构出现。重复直到完成。

我认为TDD与节奏有关(红色，绿色，重构)。降低节奏会使我们克服"不懂"的"驼峰"。而且，如果我们不放慢节奏，则很长一段时间都不会坚持使用TDD。节奏的本质是婴儿步，已经提到过。编写尽可能少的代码，并进行无情的重构。

需要强调的一件事是，TDD将一些短期收益与长期收益进行了交易。从TDD开始会不可避免地降低生产率。但是，一旦我们掌握了节奏，就可以进入节奏，实际上可以更快地工作。更不用说TDD的副作用是提供回归测试的单元测试的基础不断增长。软件的必然性是被维护的系统(没有一套自动回归测试)会随着时间的推移而退化。

强调TDD是开发人员的范式转变。如果我们要组建一个新团队，请意识到最多需要六个月的时间才能使该团队充分发挥TDD实践者的作用。一旦我们拥有一支成熟的敏捷团队有效地实践TDD，配对就可以使新开发人员经过几次迭代就能投入使用。此外，通过使用来自一个团队的对来播种新线，我们可以使新线在TDD上的速度比第一线快得多。

在我们评估的项目中，一旦团队学会了进行TDD，在自动化功能/回归测试中发现的缺陷下降了六倍。这是一笔可观的节省。此外，该代码反映了更简洁的设计，每个功能的代码行更少。 TDD但实际上是镀金的停止点。如果故事卡具有接受标准，则TDD最有效。

TDD还可以实现可持续的步伐。团队将发现，由于代码保持干净且几乎没有缺陷，因此每次迭代可以继续获得相同数量的功能。通过TDD和自动功能/回归测试，我们经常看到在用户验收测试期间发现的零缺陷。