改进反馈环节

　　很久以来，Isolator都没有一个test runner。这代表了我们的态度：用户自己选择一种好的工具，我们会兼容它。但新问题逐渐产生，在解决问题的过程中，我们不得不开始考虑开发过程的延续性了。

　　那些曾写过大型测试套件（test suite）的人都会希望测试跑的快一些。我们一直致力于让Isolator跑的更快，但我们也觉得这似乎并不是终的答案。大型测试套件执行时间确实长，但人们不必每次都要完整执行。实际上，只有那些跟你修改过的代码相关联的测试才需要执行。其他测试可以换个时间跑，比如提交之前，也可以到服务器上跑。

　　但这也不是问题的全部。有经验的测试人员看到他们三年前写下的测试时，会不敢相信自己的眼睛：我竟然写过这么烂的测试！烂的测试不仅仅是容易失败，它们有时候根本都不能算是单元测试──我们只能把它们叫做恶心的集成测试了。它们会跑的很慢。大型测试套件跑的慢的原因不仅仅是代码多而已，里面有些测试天生是慢的。

　　这时候我们仍然没有决定要写一个特别的runner，直到修bug进入了我们的视野。它一锤定音。测试失败以后，你会去检查哪部分修改导致了测试失败。你尝试理清脑海中的谜团：我干什么了？我改了哪些代码？为什么这个测试失败了，其他的还都能过？通常得调试上十次八次的，你才能把问题解决掉。

　　跟其它人一样，我们Typemock的同事们也不喜欢调试。后我们恍然大悟：这一切都是紧密联系在一起的。我们要加速完整的开发-测试体验，而不是仅仅让测试写得更快，或者跑得更快。它的目标是整个迭代式过程：写测试、跑测试、修测试，周而复始。

　　Isolator的test runner是要解决这整个一摊子问题。它会自动选择跟修改过的代码有关的测试执行。为了让反馈周期尽可能短，它还会自动忽略运行时间长的那些测试。它会显示哪些测试覆盖了哪些代码。它还可以指示出近修改的代码有哪些，指引你找到bug的可能位置。它会鼓励人用测试覆盖更多代码，于此同时还可以保证反馈周期的紧密，让写测试这件事可以持续进行。

　　小结

　　Isolator的故事讲完了。一开始的时候，我们只想解决一个问题。随着写单元测试的人越来越多，我们意识到可以为他们提供更多帮助，解决他们面对的挑战。

　　写单元测试依然不是件容易的事情。我们还在路上。