理解“测试优先”和“测试驱动”之间的区别

Question

我过去曾就此话题进行过对话，我想我可能知道答案，但我无法正确地表达出来。

以下是我认为我知道的事情：

我怀疑你是测试优先而不是测试驱动，如果你在编写测试之前已经掌握了事情将如何工作的想法，那么你首先要编写测试，然后在实现你的想法之前测试你的想法。即您对实现的想法是第一位的，并推动测试的样子。

如果您是test- 驱动，那么您正试图通过测试来推动实现的样子。您为自己想要的某些行为编写了一个测试，而不是对实现的先入为主的想法，因此您必须在“重构”阶段提出一个实现，以便将测试传递给。

我的问题是：

1. 我是否理解正确？
2. 如果大多数开发人员在他们甚至伸手去拿键盘之前立即开始探索解决方案，那么如何从测试优先思维中进入测试驱动的思维模式呢？

Answer 1

测试驱动开发的关键方面是您没有实现通过测试不需要的功能。测试优先只是意味着在实现功能之前编写测试。这主要是为了确保在功能不存在时测试实际上会失败。测试驱动开发意味着测试优先方法，但不是相反。

Answer 2

我认为你已经理解并清楚地表达了测试优先和测试驱动之间的区别，正如Björn所指出的，所有测试驱动的开发都必然是测试优先的。对于如何从测试优先到测试驱动思维模式的问题，我建议多次进行一个相对简单的练习（比如实现Range或Rectangle），每次尝试实现不同的实现。第一次，你会想出你现在想到的东西 - 而且这不是测试驱动的，正如你所指出的那样。下一次，你不能使用你正在思考的东西;你必须伸手去拿出不同的东西，其中一些将在出现失败的测试时发生。也许是第三次通过，你将开始抛弃你先入为主的解决方案，然后只做测试迫使你做的事情 - 而你正在走向以测试为导向的思维方式。

如果练习不符合您的喜好，请尽快编写第一次测试。不要事先进行分析。只是，在遇到问题时，先写一个测试。现在，您可以通过“看着你的肩膀”测试来思考问题。一段时间会感到不舒服，但出于不适应该出现一种看待问题的新方式（我认为是一个很好的方式）。

Answer 3

在实现之前编写一组测试允许您对公共方法进行单元测试。因此，测试中隐藏了正在发生的事情的真实实现。您正在编写一个抽象而不是一个实现，这是一件好事（TM）。您正在接受抽象的术语和概念 - 测试将形成您的公共方法。因此，测试驱动意味着您的测试将驱动API。反之亦然，你称之为测试优先。

Answer 4

区别在于角色和界面发现。

• 如果您在编写代码之前编写测试，则会获得Test-First徽章。
• 如果您是测试优先并且您听取测试以发现需要哪些类型/角色/接口并通过JIT重构“增长”您的设计，那么您将获得测试驱动徽章。

使用测试优先，您可能会在编写测试之前跳转到设计（可能/可能不是最简单/最佳选择;基于您的技能）。测试优先也很容易对现有设计的糟糕测试，但是进展会很慢。您最终可能会遇到难以测试的代码和速度慢的测试。

恕我直言测试驱动帮助我编写简单设计易于测试。

如何进入心态？ ：这是你需要自律和练习的部分。是的，很难让你的思维不再竞争解决方案。 +1指向Carl，指出在探索模式下做一些代码 - katas，做出不同的选择，看看它是如何结束的。有一些在你的腰带下，它变得更容易...... TDD实际上会让你一次“专注”一件事。