教学TDD时最重要的一点是[关闭]

It's about design . 它是 不是 关于测试。

不要跳过过程中的步骤。进入TDD的初始槽需要更长的时间,但一旦它就位,整个SDLC就更快,而且无缺陷性也更高。

红-绿-重构-就这样做吧。

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

除此之外,我认为在您的设计中考虑测试很重要。如果您的代码很难在不熟悉被测单元内部实现的情况下进行测试,您可能需要重新考虑设计。否则,重构变得更容易发生风险,因为测试可能必须随代码更改。

我不知道这是否算是最重要的一件事——但当我第一次使用TDD进行探索时,我花了一些时间才“了解”到这一点。

在编写测试之前,不要在头脑中编写代码。

当我第一次开始做TDD时,我“知道”设计应该是什么。我“知道”我想写什么代码。所以我写了一个测试,可以让我写这段代码。

当我这样做的时候,我并不是真的在做TDD——因为我是第一个编写代码的人(即使代码只是在我的脑子里):-)

我花了一段时间(还有一些聪明人的戳戳),才意识到你需要专注于测试。为您想要的行为编写测试——然后编写使其通过所需的最小代码——然后让设计通过重构出现。重复直到完成。

我建议,“耐心点”,一开始感觉很奇怪。对我来说,可能是三个项目让我觉得很自然。

我同意什么 Jon said in his answer 但是我认为一个重要的推论是可测试性并不决定 “好设计” 但它只是一个指标,表明您的设计符合目标。

在我看来,TDD是关于节奏的(红色、绿色、重构)。降低节奏会让你克服“没有节奏”的“驼峰”。如果你没有降低节奏,你很可能不会坚持很长时间的TDD。节奏的本质是婴儿的步伐,这已经被提到了。尽可能少地编写代码,然后无情地重构。

一件事 强调 TDD将一些短期收益与长期收益交换。从TDD开始总是会降低你的工作效率。但是一旦你学会了节奏,它就像进入了一个最佳状态,它实际上可以帮助你更快地工作。更不用说TDD的副作用是提供回归测试的单元测试不断增长的基础。软件的一个必然性是被维护的系统(没有一套自动回归测试)会随着时间的推移而退化。

强调TDD是开发人员的一个范例转变 如果你要建立一个新的团队,你要意识到,作为TDD从业者,要让团队充分发挥效力需要六个月的时间。一旦你有了一个成熟的敏捷团队,有效地实践了TDD,结对将使一个新的开发人员能够在几次迭代之后进入一个摇摆不定的阶段。此外,通过使用来自一个团队的配对来播种一条新的生产线,您可以在TDD上使新生产线的速度比第一条生产线快得多。

在我们所测量的项目中,一旦团队学会做TDD,在自动化功能/回归测试中发现的缺陷将减少六倍。这是一笔可观的节省。此外,代码反映了一种更干净的设计,每个特性的代码行更少。但实际上停止了镀金。如果你的故事卡有接受标准,TDD是最有效的。

TDD还实现了可持续的步伐。团队会发现,他们可以继续在每次迭代中完成相同数量的特性,因为代码保持干净,几乎没有缺陷。通过TDD和自动功能/回归测试,我们经常可以看到在用户验收测试期间发现的零缺陷。

当最后期限越来越紧时,处理放弃TDD的压力。这是我遇到的最大的问题之一,帮助TDD人员和团队。他们很难向更高管理层表达放弃特色而不是测试的重要性和价值。

小步前进。

确保您的测试只覆盖很小的范围,正如phlicpp所说: 执行使测试通过所需的最小编辑。 ’

尽管如此,TDD还是有很多事情要做,所以你还是要确保你不会错过任何事情。

根据我的经验,使用TDD可以让我和我的团队毫不留情地重构代码,而不用担心它会破坏一些意想不到的东西。

因此,我想对于我来说,TDD最重要的方面是覆盖率,因为良好的覆盖率让我有信心在代码库中看到可以使用它的地方时重构。

强调不同类型的测试。黑盒测试和白盒测试都很重要,并且有不同的用途。没有白盒测试来验证正确性,因为它不能测试整个系统。这样做是为了让代码闻起来更臭,从而提供更好的重构方向。黑盒测试就是为了测试正确性。每个特性都应该经过黑盒测试。

同时,强调测试覆盖率的差异。由于组合和可重复性问题,不可能黑盒测试应用程序中的每个代码路径。我的规则是,一个特性只有经过黑盒测试才能完成。你应该帮助学生制定自己的规则。然而,白盒测试不应该有外部的类依赖关系;因此,每一个类的每一行都应该被白盒测试。