TDD需要debugger吗？

　　昨天和一个同事一起pair的tdd的时候，有一个测试一直红着，我只好开了debugger来调试。这时候对面的８x，笑嘻嘻的说：

　　”tdd开debugger就是tdd的耻辱！“

真的如此吗？我们首先回顾一下tdd是的节奏red/green/refactor:

• Red　-　Write a little test that does'n work, and perhaps doesn't even compile at first.
• Green  -  Make the test work quickly, committing whatever sins neccessary in the process.
• Refactor  -  Eliminate all the duplication created in merely getting the test to work.

我们不得不开debugger的原因是因为我们不能很快的让我们的测试通过，那么怎么样才能让我们的测试很快的通过呢？很简单

　　Expected Error

如果你的测试能得到expected error，那么你自然能够很快的解决这个这个expected error；反之如果你的测试得到是一个unexpected error，你又怎么能够很快的让你的测试通过呢？而这个时候，你往往都会求助于debugger。而要让我们的每一步测试都得到一个expected error，只需要保证separate concern，也就是说你的每一步测试都只有一个关注点,　即

　　Verify One Condition Per Test

能做到这一点基本上就能保证你的每一步测试都得到一个expected error。而在我们实际的开发中，如果我们采取Inside-out的策略还好，而对于Outside-in的策略我们的测试往往就会被有很多”噪音“。举个例子，比如我们要测试一个service的某一个功能，而这个功能依赖与另外一个repository的一个保存或者更新的功能，采用inside-out的方式，你会先写这个repository的测试，然后在写service的测试，这种情况下你很容易保持测试的独立性；反之，对于outside-in你就需要先写service的测试，而这个时候你的repository根本还没有实现，而此时你service的测试必然被这个没有实现的repository所干扰。这种情况下，为了隔离这种”噪音“，stub就出现了。本来想说mock，但是我发现很多人还不能清楚的明白mock，stub，fake，dummy之间的区别，为了不干扰这篇文章的主题，以后另起一篇吧（写博客也要separate concern)。

　　TDD需不需要debugger，并不是否定debugger的作用，只是希望我们不要过分依赖debugger。而你我都知道，在我们的开发过程中debug的时间经常会超过我们写代码的时间，这是一件非常tricky的事情（也许有些人已经习惯了）。尽管现在的还不能完全说我不用debugger，但我已经在努力了，那么你呢？