我过去曾就这个话题进行过对话，我想我可能知道答案，但我无法正确表达。
以下是我认为我知道的：
如果您在编写测试之前已经对事情如何工作有想法，那么我怀疑您是测试优先而不是测试驱动，因此您首先编写测试，在实施您的想法之前测试您的想法。即您对实现的想法是第一位的，并推动了测试的样子。
如果您是测试驱动型的，那么您正试图通过测试来驱动实现的样子。你为一些你想要的行为写一个测试，而不是先入为主的实现想法，所以你必须在“重构”阶段想出一个实现才能很好地通过测试。
我的问题是：
测试驱动开发的关键方面是您不实现不需要通过测试的功能。测试优先只是意味着在实现功能之前编写测试。这样做主要是为了确保如果功能不存在，测试实际上会失败。测试驱动的开发意味着测试优先的方法，但不是相反。
我认为您已经很好地理解并阐明了测试优先和测试驱动之间的区别，并且正如 Björn 指出的那样，所有测试驱动的开发都必然是测试优先的。对于如何从测试优先到测试驱动心态的问题，我建议多次进行相对简单的练习（例如，实现 Range 或 Rectangle），每次尝试达到不同的实现。第一次通过，你会想出你现在的想法——正如你所指出的，这不是测试驱动的。下一次，你不能使用你当前的想法；你必须伸出援手才能想出一些不同的东西，其中一些接触将在测试失败的情况下发生。也许第三次通过，你'
如果您不喜欢该练习，请尝试尽快编写您的第一个测试。不要预先进行分析。只是，在处理一个问题时，先写一个测试。现在，您可以通过“回头看”测试来思考问题。一段时间内会感到不舒服，但从这种不适中应该会出现一种看待问题的新方法（我认为这是一种不错的方法）。
区别在于角色和接口发现。
使用测试优先，您可能会在编写测试之前跳到设计（这可能/可能不是最简单/最佳的选择；取决于您的技能）。测试优先也很容易将测试硬塞到一个糟糕的现有设计上，但是进展会很慢。您最终可能会得到难以测试的代码和编写缓慢的测试。
恕我直言，测试驱动帮助我编写更简单的易于测试的设计。
如何进入心态？: 那是你需要自律和练习的部分。是的，很难让你的思绪远离解决方案。+1 卡尔指出在探索模式下做一些代码型，做出不同的选择，看看结果如何。有了一些你的腰带，它变得更容易...... TDD实际上让你一次“专注”一件事。
在实现之前编写一组测试允许您对公共方法进行单元测试。因此，正在发生的事情的真正实现对测试是隐藏的。您正在编码抽象而不是实现，这是一件好事（TM）。你正在接受抽象的术语和概念——测试将形成你的公共方法。因此，测试驱动意味着您的测试将驱动 API。反过来就是你所说的测试优先。