理解“测试先行”和“测试驱动”的区别

Question

我之前曾经讨论过这个话题，我认为我可能知道答案，但是我无法很好地表达出来。

这是我认为的：

如果您在编写测试之前已经有了如何实现事物的想法，那么您很可能是“测试先行”，因此在实施您的想法之前首先编写将测试您的想法的测试。也就是说，“实现想法的思路驱动测试的设计。”

如果您是“测试驱动”的，则试图使测试驱动实现的外观。您编写一些行为的测试而不是预先设定的实现方式，以便在“重构”阶段中制定实现方案以通过测试。

我的问题是：

1. 我理解得对吗？
2. 当大多数开发人员在开始使用键盘之前就立即开始探索解决方案时，如何从“测试先行”的心态转变为“测试驱动”的心态？

- Neil Barnwell

---

如果有人想留下评论提出修改建议，以避免此问题被关闭，我将非常欢迎。请仅返回翻译后的文本内容。 - Neil Barnwell

也许应该转到http://programmers.stackexchange.com/，因为那里似乎更合适？ - Sardathrion - against SE abuse

哦，亲爱的。我真的很遗憾程序员问答网站被创建了，因为SO.com在其关于页面上被描述为“一个编程问答网站”。这到底怎么区分呢？好吧，谢谢你的提示。 - Neil Barnwell

看看两个常见问题解答（FAQs）。请注意，由于我的“whuffies”很低，您应该带着怀疑的心态看待我的回答 —— 我可能会错。 - Sardathrion - against SE abuse

可能是 https://dev59.com/tHRC5IYBdhLWcg3wUvUS 的重复问题，TDD 和测试先编程或测试先开发之间有区别吗？ - Raedwald

Answer 1

测试驱动开发的关键是不会实现不需要通过测试的功能。先测试意味着在实现功能之前编写测试。这主要是为了确保如果功能不存在，则测试将失败。测试驱动开发暗示了先测试的方法，但反过来并不是这样。

- Björn Pollex

---

一个相关的问题：https://dev59.com/IHVC5IYBdhLWcg3wfhOL - Raedwald

Answer 2

我认为你已经很好地理解和表达了测试优先和测试驱动之间的区别，正如Björn所指出的，所有测试驱动开发都必须是测试优先的。对于你如何从测试优先转向测试驱动的思维方式的问题，我建议多做一个相对简单的练习（比如实现Range或Rectangle），并尝试每次都采用不同的实现方式。第一次尝试时，你会想到你现在正在考虑的东西，这不是测试驱动的，正如你所指出的那样。下一次尝试时，你不能使用当前的想法；你必须寻找其他不同的方法，并且在失败的测试存在的情况下进行一些探索。也许第三次尝试时，你将开始放弃自己的预设解决方案，只是按照测试要求去做，这样你就可以走上测试驱动的思维方式。

如果这个练习不适合你，可以尝试更早地编写第一个测试。不要事先分析，只需在解决问题时首先编写一个测试。现在你可以在测试“看着你的肩膀”时思考问题。一段时间内可能会感到不舒服，但从不适中应该会出现一种新的方式（我认为是一种不错的方式）来看待问题。

- Carl Manaster

Answer 3

编写一组测试用例，然后再进行实现，这样可以让你为公共方法编写单元测试。因此，真正发生的实现被隐藏在测试之后。你是在编写抽象而不是具体的实现，这是一件好事（TM）。你正在使用抽象术语和概念——测试将形成你的公共方法。所以，测试驱动意味着你的测试将驱动API。相反，测试优先是指先编写测试用例。

- Sardathrion - against SE abuse

Answer 4

区别在于角色和接口探索。

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

使用Test-First，你可能会在编写测试之前跳到一个设计（可能不是最简单/最优选择；基于你的技能）。 Test-First也容易将测试嵌入到现有的不良设计中，但进展会很慢。你可能最终会得到难以测试的代码和编写缓慢的测试。

在我看来，Test-Driven帮助我编写更简单、容易测试的设计。

如何进入心态？：这就需要自律和实践了。让你的思维不要急于求成确实很难。Carl指出，在探索模式下进行一些代码卡塔练习，做出不同的选择并看看结果如何。经过几次尝试后，变得更容易……TDD实际上使你集中精力专注在一件事情上。

- Gishu