手表测试失败
为什么在编写测试后立即观察测试失败如此重要？这怎么有道理呢？
我知道这会失败，浪费时间。
Why is that so important to watch the test fails right after writing it? How that makes sense?
I know that it will fail, time wasting.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
编写失败的测试有很多优点。
从根本上来说：如果您编写了一个通过的测试，那么您就没有进行测试驱动的开发，因为导致测试通过的开发发生在编写测试之前。类似地，对于测试驱动设计，如果您更喜欢这个短语（就像我一样）；导致通过测试的开发的设计发生在您编写测试之前。但这在某种程度上只是定义性的。 TDD 的条款和流程对您来说可能并不那么重要。
在更实际的层面上，失败的测试会导致更小的解决方案。当您编写足够的代码来通过单个失败的测试时，您（通常）只在之前的代码上添加了一点。您知道该新位是满足该测试的代码部分；你知道它为什么在那里。然后，您为下一个小增量功能编写下一个失败的测试。你不会过度设计你的解决方案；你建造的就足够了。
因为失败的测试会导致您进行小步增量开发，所以您的开发流程会更好。你不再需要长时间埋头编码，中间夹杂着疯狂的调试和丢弃，而是稳步前进。当你丢弃的时候，你丢弃的东西很小；重新开始很容易，因为您不会浪费数小时或数天的工作。当您调试时，您知道问题（很可能）出在新代码的一小部分中。
失败的测试可以让您了解您的代码，以及（更重要的是）您对代码的理解；他们告诉你“是的，你对代码没有做 X 的理解是正确的，并且你已经正确且具体地表达了这种理解”，或者“不 - 出了点问题”。另一方面，全新的通过测试只会告诉您“是的，它似乎有效”，但这有时可能是因为测试是错误的。
There are a lot of advantages to writing a failing test.
Fundamentally: if you write a passing test, you aren't doing test-driven development, because the development that causes the test to pass happened before the test was written. Similarly for test-driven design, if you prefer that phrase (as I do); the design that led to the development that passes the test happened before you wrote the test. But that is, to some extent, just definitional; the terms and the process of TDD may not be that important to you.
On a more practical level, failing tests lead to to smaller solutions. When you write just enough code to pass a single failing test, you (frequently) add only a bit to what you had before. You know that that new bit is the part of your code that satisfies that test; you know why it is there. And then you write the next failing test, for the next small incremental bit of functionality. You don't overengineer your solution; you build just enough.
Because failing tests lead you to small-step incremental development, your development flow is better. Instead of long periods of heads-down coding, punctuated by frantic episodes of debugging and discarding, you move steadily forward. When you do discard, what you discard is very small; it's easy to start over because you are not throwing away hours or days of work. When you debug, you know the problem is (very probably) in a very small part of new code.
Failing tests inform you about your code, and (more important) your understanding of your code; they tell you either "Yes, your understanding that the code didn't do X is correct, and you have expressed that understanding correctly and concretely," or "No - something's wrong". Brand new passing tests, on the other hand, only tell you "Yes, it seems to be working," but that can sometimes be because the test is wrong.
这样您就可以确保正确编写测试。如果成功，那么您就知道您在编写测试时搞砸了。
So that you can make sure you wrote your test correctly. If it succeeds, then you know that you screwed up in writing your test.
说“我知道它会失败”与“我知道它会成功”相关。如果后者确实是真的，那么您的程序就不会有任何错误;-) 与测试失败相同：您只有尝试过才真正知道。
Saying "I know that it will fail" is related to "I know that it will succeed". And if the later would really be true your program wouldn't have any bugs ;-) Same thing with failing a test: you only really know once you've tried.
实际上，重点是观察失败测试的消息。它如何捕获您的代码的问题？它的表现力如何？
您必须调整您的测试，直到消息准确说明您的代码有什么问题。当将来当你刹车时测试失败时，这会让你的生活变得更轻松，这就是重点。
Actually the point is to watch the message of the failing test. How it captures the problem with your code? How expressive is it?
You have to adjust your test until the message exactly says what's the problem with your code. It will make your life easier a lot when the test will fail in the future when you brake something and that's the point here.