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

Question

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

现在我在大约12个月前开始了这个项目，但我只是轻松地开展这项工作，我刚刚开始将更多的时间都集中在它上面（几乎每天晚上）。

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

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

编辑：我刚刚补充了一点，以澄清我的意思是与“方向感”斗争，如果没有澄清，这不是最好的说法。

Answer 1

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

然而......（总有一个“但是”）......

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

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

Answer 2

是

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

也许可以考虑查看Brownfield Application Development in .NET？对于这种情况，它充满了实用和实用的建议（“Brownfield”提供的定义之一是“没有适当的单元测试”）。

Answer 3

是的，开始做TDD绝对是一个好主意。

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

1. 学习新技能TDD /单元测试。
2. 将您的代码改进为可测试。

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

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

Answer 4

更糟糕的是，您可以在新内容上进行TDD，同时慢慢为现有代码库创建测试。

Answer 5

是的，开始使用TDD永远不会太晚。我已经将TDD引入到我加入时已经运行了五年的商业项目中，这绝对是一个很好的决定。

虽然你不熟悉这种技术，但是你应该专注于将它用于你正在编写的代码 - 新类，新方法等。一旦你抓住它，就开始编写代码测试你改变了。

对于某些代码，后者可能会被证明是困难的，因为到目前为止您编写的代码不太可能在编写时考虑到可测试性。有一些技巧可以解决这个问题，但关心它们可能还为时过早。

如果您缺少方向感，我怀疑TDD会对您有所帮助。您可能希望查看验收测试，这至少与单元测试一样重要，并且将帮助您专注于系统的功能而不是单个代码单元。 Lasse Koskela撰写的TDD书很好地介绍了两种技术。

另一种可能对您有帮助的技术是极限编程规划游戏，您可以在索引卡上放置一些功能并对其进行优先级排序。我通常会注意到，从我的头脑和优先顺序中获取想法可以帮助我理解我想要去的地方。

Answer 6

正如其他人所说，TDD不应该损害正在进行的项目，但要仔细考虑是否想要进行大规模重构以便进行测试。确保收益合理化。

我有点担心你“挣扎着方向感”。我不知道TDD会帮助你。我发现这对于低级设计决策是一个很好的帮助，但对于架构决策来说并不是那么好。将TDD添加到无方向项目听起来有点像生孩子来挽救婚姻 - 不明智。希望我误读你的意图。

Answer 7

是

TDD使其他人更容易理解代码，并且随着时间的推移为应用程序提供更好的设计

Answer 8

理论上你应该先测试，但你没有。在这种情况下，与其他人的意见相反，我不会从新功能开始。

• 利用80:20规则，运行一个分析器，并将测试用例放到最常被调用的代码段中。
• 在房子的宝石，肠道，最重要的代码周围进行测试。
• 围绕恼人的，经常破碎的，经常发生的似曾相识的错误代码进行测试。
• 在修复错误测试错误之前，对您遇到的所有错误进行测试。

警告：放置测试用例需要重构，这意味着你必须修复一些没有破坏的东西。

如果您现在仍然喜欢单元测试，那么您将自己进行红色，绿色，重构。

Answer 9

绝对

将TDD引入新代码，如果时间允许，请在现有代码中引入“评论驱动设计”（如果尚未测试）。

• 注释掉您需要测试的现有代码块
• 编写测试
• 一次取消原始代码一个语句（如果你有一个if块，取消注释整个块）
• 确定您的原始代码是否最终通过了测试，如果没有，请重新编写以相应地传递测试

Answer 10

为您不打算更改的现有工作代码编写测试不符合TDD的推动力，这就是编写测试，告诉您正在构建的系统。

我引入TDD中流的方法是：

• 为所有新功能编写测试，
• 在更改一段代码时，编写一个涵盖现有功能的测试（以确保我理解它），然后在更改代码之前更改测试。

为与您正在更改的代码相关的代码编写测试也是有益的 - 例如，如果您正在更改父类，您可能希望首先围绕子类构建测试以保护自己免受潜在的损害。< / p>

Answer 11

是的，你应该。我目前正在开发一个直到最近才进行单元测试的项目，但我们决定开始测试代码，所以我们现在开始编写它们。不幸的是，我是唯一一个练习TDD的开发人员，其他人只是在编写代码后编写测试 尽管如此，我发现练习TDD可以帮助我编写更好的代码，而且我写得比以前更快。现在我学会了如何做TDD，我只是不想像以前那样回去编写代码。