我是否应该开始在不使用TDD的项目上使用TDD

我有一个项目,我已经工作了一段时间,只是我希望有一天发布开源的小宠物项目之一.

现在我大约12个月前开始了这个项目,但我只是轻松地开展这个项目,我刚开始把更多的时间都集中在它上面(几乎每天晚上).

因为它是一个类似于应用程序的框架,所以我有时会因为我没有任何事情来推动我的设计决策而挣扎于方向感,有时我最终会制作难以使用甚至找不到的功能.我一直在阅读有关如何做TDD的想法,也许这会帮助我解决一些我遇到的问题.

所以问题是你认为在一个尚未使用它的项目上开始使用TDD是一个好主意.

编辑:我刚刚添加了一点来澄清我的意思是与"方向感"斗争,如果没有澄清,这恰好不是最好的说法.

1> Bevan..：

---

在我看来,采用更好的做法永远不会太晚 - 或者更糟糕的做法 - 所以我会说"是的,你应该开始".

但是......(总有一个"但是")......

... TDD最大的收获之一是它会影响您的设计,鼓励您将reponsibilties分开,交互清洁等等.

在项目的这一点上,您可能会发现很难为框架的某些方面编写测试.不要放弃,即使你无法测试某些区域,你的质量对于你可以测试的区域来说会更好,你的技能也会因为体验而提高.

---

迈克尔·费瑟斯(Michael Feathers)的着作"有效地使用遗留代码"(Legacy Code)充满了很好的建议,可以让你的框架中的"困难"部分得到测试.

2> Marc Gravell..：

---

是.

基本上,您不能通过为您编写的任何新代码添加TDD以及对现有代码所做的任何更改来造成任何伤害.显然,返回并对现有代码进行精确测试可能会很复杂,但覆盖主要用例肯定不会受到影响.

也许可以考虑一下.NET中的Brownfield Application Development？对于这种情况,它充满了实用和实用的建议("Brownfield"提供的定义之一是"没有适当的单元测试").

3> Jeffrey Fred..：

---

是的,开始做TDD绝对是个好主意.

您将支付启动费用至少有两个原因:

学习新技能TDD /单元测试.

改进您的代码以使其可测试.

你需要做两者兼而有之,但是当你发现自己在努力工作时,想一想这两者中哪一个是努力的源泉.

但最终结果是值得的.根据您的描述,这是一个您打算与之共存一段时间的项目.请记住,当你在这里或那里失去一个小时.在一年中,您会非常高兴您在技能和代码库中进行了这项投资.