我知道TDD有很多帮助,当你第一次创建测试然后实现这个功能时,我喜欢这种开发方法.这是非常明确和正确的方式.
但由于我的项目有一些风味,经常发生的是,当我开始开发一些模块时,我对我想要的东西知之甚少,以及它最终会如何看待.这些要求在我开发时出现,当我删除全部或部分旧代码并编写新代码时,可能会有2或3次迭代.
我看到两个问题:1.我希望尽快看到结果,理解我的想法是对还是错.单元测试会减慢此过程.因此,在代码完成之后我经常会编写单元测试,这是一个糟糕的模式.2.如果我第一次编写测试,我不仅要重写代码两次或更多次,还要重写测试.这需要很长时间.
有人可以告诉我在这种情况下如何应用TDD？
提前致谢!
Mar*_*ers 12
我希望尽快看到结果,了解我的想法是对还是错.单元测试会减慢此过程.
我不同意.单元测试和TDD通常可以加速获得结果,因为它们会迫使您专注于结果,而不是实现您可能永远不需要的大量代码.它还允许您在编写代码时运行代码的不同部分,这样您就可以不断查看获得的结果,而不必等到整个程序完成.
我发现TDD在这种情况下效果特别好; 事实上,我认为不清楚和/或不断变化的要求实际上非常普遍.
我发现TDD的最佳用途是确保您的代码正在按照您的预期执行.当您编写任何代码时,您应该知道您希望它做什么,是否要求是明确的.这里TDD的优势在于,如果需求发生变化,您只需更改一个或多个单元测试以反映更改的需求,然后更新代码,同时确保您不会破坏其他代码(不变) )功能.
我认为使用TDD绊倒很多人的一件事是假设所有测试都需要提前编写.我认为使用经验法则更有效的是,当你的所有测试都通过时,你永远不会编写任何实现代码; 这只是确保所有代码都被覆盖,同时还确保您检查所有代码是否符合您的要求,而不必担心预先编写所有测试.
恕我直言,你的主要问题是你必须删除一些代码.这是浪费,这是首先要解决的问题.
也许您可以使用原型,或利用"尖峰解决方案"来验证需求,然后在需求稳定后,将TDD应用于实际代码.
风险是应用这个并且必须运送原型.
此外,您可以先测试"阳光路径",然后仅在要求被固定后才实现剩余的错误处理等.然而,实施的第二阶段将不那么激励.
你使用什么开发过程？当你进行迭代时,它听起来很敏捷,但在完全支持迭代的环境中则不然.
| 归档时间： |
|
| 查看次数： |
582 次 |
| 最近记录： |