在做TDD时你如何保持纪律？

Question

当我对即将实现的新功能或者我刚刚“理解”的错误感到兴奋时，就会有冲动进入代码并进行黑客攻击的冲动。需要一些努力来阻止自己这样做并首先编写相应的测试。后来测试经常变成琐碎的4线，但在写之前仍有脑袋后面的想法，“也许我可以跳过这一次，这一次？”理想情况下，我想要写一个测试的冲动，然后才可能代码：）

您使用什么方法（或思维或思维方式或自我奖励政策或其他方式）来帮助维持纪律？或者你只是练习它直到感觉自然？

Answer 1

我喜欢测试的即时反馈，这对我来说是足够的回报。如果我可以在测试中重现一个感觉良好的错误，我知道我正朝着正确的方向前进，而不是猜测并可能浪费我的时间。

我喜欢在Test-First工作，因为我觉得它让我更加关注代码实际上做的事情，而不是基于可能不准确的心理模型进行猜测。能够迭代地确认我的假设对我来说是一个巨大的回报。

Answer 2

我发现编写测试有助于我勾勒出我对手头问题的处理方法。通常情况下，如果你不能写出一个好的测试，那就意味着你没有必要考虑到你应该做的事情。对测试编写后我知道如何解决问题的满意度是非常有用的。

Answer 3

当我找到一种有效的方法时，我会通知您。 ： - ）

但严重的是，我认为你的“练习直到它感觉自然”的评论几乎击中了头部。 4线测试可能看起来微不足道，但只要您测试的是真正的失败点，那么值得做。

我发现有用的一件事是将代码覆盖率验证作为构建过程的一部分。如果我没有写测试，那么构建会向我抱怨。如果我继续无法编写测试，持续集成构建将“出错”，并且附近的每个人都会听到我连接到“破坏的构建”通知的声音。经过几周的“好悲伤......你又把它打破了？”，以及类似的评论，我很快就开始写更多的测试来避免尴尬。

另一件事（我第一次提交答案后才发生这种情况）是，一旦我真正养成了先写测试的习惯，我就能得到很好的补充，因为我可以提供错误 - 修复和其他功能比我在自动化前测试日期间的信心更强。

Answer 4

我发现最简单的方法就是使用TDD。在某些时候，编写没有单元测试的代码会变得非常非常紧张。

此外，尝试专注于交互或行为测试，而不是基于状态的测试。

Answer 5

wear a green wristband

Answer 6

1）您与团队中的其他人配对。一个人写测试，另一个人实现。

它被称为“乒乓球”配对。

这样做会迫使您讨论设计并找出要做的事情。

通过此讨论还可以更轻松地查看您将需要的测试。

2）当我独自工作时，我喜欢以交互方式尝试大量代码。我只是在红宝石提示符下键入它们。当我正在进行这样的实验时，我经常需要设置一些数据进行试验，并使用一些打印输出语句来查看结果。

这些小小的，自给自足的一次性实验通常是：

• 确定实施可行性的快捷方法，
• 开始正式化测试的好地方。

Answer 7

我认为，就TDD而言，保持自我检查的重要部分是正确设置测试项目。这样添加一个简单的测试用例确实是微不足道的。

如果要添加测试，您需要首先创建一个测试项目，然后找出隔离组件的方式，何时模拟事物等等，它们会变成太难的篮子。

所以我想回到将单元测试完全集成到您的开发过程中。

Answer 8

当我在2000年左右开始做TDD时，感觉非常不自然。然后是.net的第一个版本和NUnit的JUnit端口，我开始在Shu级别（Shu-Ha-Ri）练习TDD，这意味着测试（第一个）所有内容，与你的问题相同。

几年后，在另一个工作场所，我们与一位非常敬业，称职的高级开发人员一起，采取了必要的措施来达到Ha水平。这意味着，例如，不是盲目地主演报道报道，但问题是“这种测试真的很有用，它是否会增加价值而不是成本？”。

现在，在另一个工作场所，与另一位伟大的同事一起，我觉得我们正朝着Ri级迈出第一步。对我们而言，目前意味着非常关注BDD /可执行文件。有了那些在更高级别验证需求的地方，我感觉更有效率，因为每次类的公共接口需要更改时，我不需要（重新）编写一堆单元测试，用以下内容替换静态调用扩展方法，等等。

不要误解我的意思，通常的TDD类测试仍在使用，为我们提供了很大的价值。这很难用语言表达，但我们在“感觉”和“感知”哪些测试有意义，以及如何设计我们的软件方面，比十年前的能力要好得多。