我坚持去健身房锻炼身体，练习举重，我喜欢这种让自己变得更强壮、更健康的感觉。大约两个月前，我的膝盖开始感觉抽痛，但我仍然坚强去锻炼。

我一心想让自己更强壮，完全忽视了腿上的健康问题，仍然强迫自己继续举重。你可以想象出，膝盖上的痛没有好转，每一次精疲力尽的锻炼后我都需要更长时间的恢复。

作为一个在Rackspace公司的初级程序员(在Airbrake开发组)，我经常会有一种相似的感觉，它催促我不停的大量产出代码，以为这样能让产品更强壮。当正如我的膝盖每次在下蹲时都要忍受痛苦一样，未经测试的老的功能特征在大量出现的新功能的重压下开始变形，开始断裂。

最终我的理疗师说服我应该重点做康复锻炼，恢复前不要再去举重。他说，当膝盖上的问题好了之后，肌肉变得更结实有力后，我的进步会更快，也更不容易弄伤自己，让自己痛苦。

铭记了这些忠告，我看到了它和工作之间的联系。我强迫自己去给老代码、老功能写测试代码，这样使得我的开发进度更快，对代码更有信心，不再担心开发新代码时会破坏老代码的功能。

下面是我在这个转变过程中学到的关键几点：

开发工具很重要

我使用RSpec, Capybara, FactoryGirl和Selenium来测试我的Rails应用。在写测试代码之前，你要先研究一下这些工具。否则，调试这些测试代码浪费你大量的时间。

一些简单的任务，例如在测试前和测试后清除数据库，它们对保证你能正确的、快速的、可重复的测试起着重要作用。对于这些任务，你可以使用这个database_cleaner gem。

如果你是团队中第一个来写测试代码的人，这个时候测试工具的选择尤其重要，它会影响团队其他成员对测试的接受。整个团队都要提交测试程序，所以你要让这个过程尽可能的简单，——采用强大、灵活的工具。

现有的代码只是告诉你现在做成了什么样，但不是告诉你代码实际应该是这样。

当开始测试别人的代码时，我发现有个习惯，首先假设这些代码是正确的，符合要求的，所以这些代码中能够通过测试用例。有时这样是没问题的，但有时这些代码之所以通过测试只是因为测试代码是按照它们写的。

你忍不住会图省事，会假设所有的这些代码是最新的，符合要求的，然后写的测试来证实这些假设。这就导致了一种反向的测试驱动开发模式：代码成了测试的依据和标准。

安全的做法是探求代码最初的意愿，资深的程序员更喜欢写出很明晰的代码，你能通过代码看出它试图实现的功能。

完全测试是不可能的，不要这样要求自己

为整个项目写测试程序，你可能需要将它当作一种全职工作来对待。当然，我们都希望100%(+)的测试覆盖率，就像我们都希望洗涤盆里没有脏盘子。然而，另外一种方法是当你需要盘子时清洗所需的盘子。我们用这种策略为新代码写测试程序，老代码中我们开发的过程中遇到时再写测试程序。

我建议新程序员应该去为老程序写测试，这样它能强迫你学习老代码库，让你获得更深的肌肉记忆力。但一定要遵循上面的这些原则。