了解“测试优先”和“测试优先”之间的区别和“测试驱动”
我过去曾讨论过这个话题，我想我可能知道答案，但我无法正确地表达出来。
这就是我所知道的想法：
如果在编写测试之前您的头脑中已经有了关于事情将如何工作的想法，那么我怀疑您是测试优先而不是测试驱动，因此您首先编写测试这将在实施您的想法之前测试您的想法。即，您对实现的想法是第一位的，并驱动测试的外观。
如果您是测试驱动的，那么您会尝试让测试驱动什么实施看起来像。您为所需的某些行为编写测试，而不是先入为主的实现想法，因此您必须在“重构”阶段提出实现才能顺利通过测试。
我的问题是：
- 我理解正确吗？
- 当大多数开发人员在伸手触摸键盘之前就自然地开始在脑海中探索解决方案时，如何从测试第一的思维方式转变为测试驱动的思维方式？
I've had conversations about this topic in the past, and I think I might know the answer, but I've not been able to articulate it properly.
Here's what I think I know:
I suspect you are test-first rather than test-driven if you already have the idea in your head of how things will work before you write tests, so you write tests first that will test your idea before implementing your idea. I.e. Your idea of the implementation comes first, and drives what the tests look like.
If you're test-driven then you're trying to get the test to drive what the implementation looks like. You write a test for some behaviour you want rather than a preconceived idea of the implementation, so that you have to come up with an implementation in the "refactor" stage to pass the test well.
My questions are:
- Have I understood this correctly?
- How does one get into the test-driven mindset from the test-first mindset, when it's natural for most developers to immediately start exploring solutions in their mind before they even reach out for the keyboard?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
测试驱动开发的关键方面是您不会实现通过测试不需要的功能。测试优先只是意味着在实现功能之前编写测试。这样做主要是为了确保如果功能不存在，测试实际上会失败。测试驱动开发意味着测试优先的方法，但反之则不然。
The key aspect of test-driven development is that you do not implement functionality that is not required to pass a test. Test-first simply means writing the test before you implement the functionality. This is mostly done to ensure that the test will actually fail if the functionality is not present. Test-driven development implies a test-first approach, but not the other way around.
我认为您已经很好地理解并阐明了测试优先和测试驱动之间的区别，并且正如 Björn 指出的那样，所有测试驱动开发都必然是测试优先。对于如何从测试优先转变为测试驱动心态的问题，我建议多次进行相对简单的练习（例如，实现范围或矩形），尝试每次都达到不同的实现。第一次通过时，您会想出您现在的想法 - 正如您所指出的，这不是测试驱动的。下一次，你就不能再用你现在的想法了；你必须努力想出一些不同的东西，而其中一些成果将在测试失败的情况下发生。也许第三次，你会开始放弃你先入为主的解决方案，而只是做测试迫使你做的事情 - 然后你就走上了测试驱动的心态。
如果您不喜欢这个练习，请尝试尽快编写您的第一个测试。不要预先进行分析。只是，在解决问题时，首先编写一个测试。现在您可以通过“回头看”测试来思考问题。暂时会感到不舒服，但在这种不舒服中应该会出现一种看待问题的新方法（我认为这是一个很好的方法）。
I think you've understood and articulated pretty well the distinction between test-first and test-driven, and as Björn points out, all test-driven development is necessarily test-first. To your question of how to get from a test-first to a test-driven mindset, I'd suggest working a relatively simple exercise (say, implementing Range or Rectangle) several times, trying to arrive at a different implementation each time. The first time through, you'll come up with what you are thinking of right now - and that's not test-driven, as you point out. The next time through, you can't use what you're currently thinking; you'll have to reach out to come up with something different, and some of that reaching will happen in the presence of a failing test. Maybe the third time through, you'll begin to discard your preconceived solutions, and just do what the test compels you to do - and you're on your way to a test-driven mindset.
If the exercise is not to your liking, try simply writing your first test sooner. Don't do the analysis up-front. Just, on taking on a problem, first write a test. Now you can do your thinking about the problem with the test "looking over your shoulder". It'll be uncomfortable for a while, but out of the discomfort should emerge a new way (and I think a nice one) of looking at problems.
在实现之前编写一组测试允许您对公共方法进行单元测试。因此，测试中隐藏了正在发生的事情的真正实现。您正在编码抽象而不是实现，这是一件好事（TM）。您正在接受抽象术语和概念——测试将形成您的公共方法。因此，测试驱动意味着您的测试将驱动 API。相反的就是所谓的测试优先。
Writing a set of tests before implementation allows you to make the unit tests for the public methods. So, the real implementation of what is happening is hidden from the test. You are coding to an abstract rather than an implementation which is a good thing (TM). You are taking in abstract terms and concepts -- the tests will form what your public methods will be. So, test driven mean that your tests will drive the API. The reverse is what you call test-first.
区别在于角色和接口发现。
使用测试优先，您可能会在编写测试之前跳转到设计（这可能/可能不是最简单/最佳的选择；根据您的技能）。测试优先也很容易将测试硬塞到糟糕的现有设计上，但进展会很慢。您可能最终会遇到难以测试的代码和编写缓慢的测试。
恕我直言，测试驱动可以帮助我编写更简单且易于测试的设计。
如何进入心态？ : 这就是你需要自律和练习的部分。是的，你很难不去思考解决方案。 +1 Carl 指出在探索模式下做一些代码型，做出不同的选择，看看结果如何。有了一些掌握，事情就会变得更容易…… TDD 实际上会让你一次“专注”于一件事。
The difference is Role and Interface discovery.
With test-first, you're likely to jump to a design (which may/may not be the simplest/optimal choice ; based on your skill) before you write the tests. Test-first is also easy to shoehorn tests onto a bad existing design, however progress would be slow. You're likely to end up with hard-to-test code and slow-to-write tests.
IMHO Test-driven helps me to write simpler designs that are easy to test.
How to get into the mindset ? : That's the part where you need self-discipline and practice. Yes it is difficult to keep your mind from racing to solutions. +1 to Carl for pointing doing some code-katas in exploratory mode, Make different choices and see how it ends up. With a few under your belt, it becomes easier... TDD actually causes you to "focus" on one thing at a time.