如何将范例转换为测试驱动的开发

获取TDD的最佳方法是继续并做到这一点。到目前为止,这是我设法让同事“测试感染”的唯一方法——至少现在你已经很好地了解了预先的好处。

不过,从一个更实际的角度来看,我认为您已经强调了一个关键的想法——这是在规划构建应用程序的需求方面的一个变化。无论你目前使用的是什么方法,如果你看到一个像“需求”这样的词,你可以在精神上思考“测试用例”,并且至少有 意图 首先编写测试用例。但正如其他答案所表明的那样,TDD并不是一个完全或完全的决定。任何你写的测试,无论你在写它之前还是之后,都是有用的。同样地,不要认为你能达到预先编写所有测试的状态——这是一个循环。

我最喜欢的是伪代码 this item in the JUnit FAQ . 测试用例的思想框架是一个无限循环。任何地方都可以参加,你写的任何测试都会有帮助,你不会后悔的。

你还可以最后测试。没关系。我们会原谅你的。

了解单元测试工具在当前语言中的工作方式。

现在就开始为你正在做的任何工作编写单元测试。

最后,您可以进行一点代码测试。然后测试一点代码一点。

纯试验 驱动 发展是理想。实际上,大多数人只需测试一点代码。更像是测试转向或测试引导,而不是测试驱动。

现在就开始。测试你手头的所有东西。

你需要 实践 .

你可以从 测试一次编程 .按照通常的方式设计代码,也许并没有深入的细节,并且首先开始实现它的测试:从一个没有依赖性的类开始,看看如何测试它,写下一个可以想到的测试列表。开始编写最简单的测试。然后写足够的代码让它通过。在列表上交叉测试并编写它,编写代码。

当您对一个新的测试有了一个想法或者问自己一个关于代码在特定条件下的行为的问题时,请向您的列表中添加一个新的测试。

我建议你阅读 Test Driven Development ;这是对TDD的一个很好的介绍,也包含了很多参考资料(称为模式)。

关于估计值,需要记住的一点是,尽管同时编写代码和测试比只编写代码稍微长一些,但最终 工作代码 .

还有一些建议,一旦你开始:

• 在修复代码中的任何问题之前添加新的失败测试。

• 尽量不要在没有失败测试的情况下编写任何代码行——这是最终目标。

我不明白你为什么不能开始使用TDD。您不需要使用这个实践来创建所有的代码——只需将它用于一天一节课,或者一天一小时,作为开始。当您感到更舒服时,可以将实践的应用程序扩展到更多的代码中。

还请记住,TDD更多的是一种设计策略,而不是一种测试策略。对测试告诉您的关于生产代码的内容保持开放。总是无情地重构——尤其是在开始的时候,如果有疑问的话,错误的重构太多了。

如果你能找到一些喜欢的人,可以考虑进行编码Dojo;这是学习新编程技能的一个非常有趣的方法: http://codingdojo.org/

除了S.Lott所说的,看看MVC店面是如何构建的。

他们如何处理来自数据库的数据的测试? 他们如何处理控制器正常运行的测试?当类具有其他依赖项时,它们如何处理?

看看TDD是如何要求你构建一个程序的,一旦你已经过了(?)的基础知识,这将是非常有帮助的。??)单位

即使你是先写代码,在写代码的时候也要问问自己,“这是可测试的吗?”如果不是这样,那么您可能需要重新考虑针对您正在编写的特定代码段的设计。如果是,那么继续并完成它,然后写一些测试。我现在正处于一种有点测试的心态中。