Chapter 7. Testing and Debugging

如果您是略读本书，你也许会跳过这章。毕竟，现在还没有构建需要测试的应用，为什么要看测试呢？为什么在技术环节上还没有出错要学习调试呢？其实答案很简单：测试和调试应该出现在开发的每一个阶段，甚至是开发之前。这里的原因有几条：首先，众所周知，完整的测试可以使应用更加可靠。其次，写测试可以加快开发的速度。这点不太好接受，但这是事实。因为测试行为就像是登山时用的安全带一样：减少了因为错误而引发的问题，可以令你放手去写代码，从而加快开发速度。 

在每种语言和平台环境下，都会做自动化测试的工作。但并不是每一种技术都把测试放在同等重要的位置，典型的例子就是javascript，经常不写任何的测试。不过幸运的是，Ruby和rails都有很浓厚的测试文化。大量的Ruby项目都包含有测试代码，而且rails本身有一个非常完善的测试框架。Rails也鼓励开发者测试自己的应用。对于每个使用script/generate生成的model或是controller都会自动的添加对应的测试文件。这就是rails的方式，时刻提醒你尽早的测试你的代码。 

Ajax也有新的方式来测试和调试，比较繁琐。在这章，我们会介绍这些工具和技术，利用他们帮助你开发更加健壮的应用程序。 

使用支持ruby变成和其他语言的工具来进行Javascript开发常常比较困难。不过幸运的是，有越来越多的支持开发的工具出现，这将有助于你的工作更富有成效。 

在这章，我们首先来看下调试技巧和调试工具，然后是测试技术，最后介绍一些用来捕捉遗留bug的方法。 
7.1. Debugging 
一般来说，调试可以归结为使正确信息可视化的过程。所有的调试工具都企图彻底的达到这个目的，例如，日志文件，监控器和断点都会帮助你将复杂的交互分割成一个个小块儿，这样你就可以排除某些特定的原因，将问题控制在一个比较狭窄的空间内。让我们来看一些调试工具：Rails的异常画面显示，日志，控制台和监控器。 
7.1.1. Understanding Rails Exceptions 
在开发环境下，任何会导致错误或异常的动作都会产生一个异常调试画面，如图所示：

    
如果你使用过Rails进行web开发，应该很熟悉这个窗口信息。下面我们来看看这里面到底说了些什么。开始的那几句是最重要的，标题显示的信息告诉所抛出异常的名字和产生异常的action位置（例如，ControllerName和ActionName）。在这个标题的下方所显示的代码，Rails会准确的给出出错的文件和有问题的代码行，甚至显示在这行出错的代码上方有一小段文字说明。通常情况下，结合异常消息和这行出错的代码可以帮助你很快的修正错误。在这个例子中，异常消息（undefined method ’title’ for #<Message:24959f0>）提供了这样一个线索：我们正在让Message类的一个实例对象调用一个叫做title的方法，但是这个对象不支持这个方法。看看出错的源代码，唯一出现title的地方是在text_field这个helper中，作为一个变量出现的。所以错误出在哪呢？最大的可能是在模型类中对这个属性名的拼写发生了错误。马上通过检查（未显示在上图中），证实了我们的怀疑：实际字段的名字是name而不是title。 

有些情况下，问题并不明显。摘录出来的发生错误的代码仅仅显示的是视图级的异常引发原因，但以此并不足以推断是视图里（view）的代码错误。如果是在视图里从模型或者帮助文件中调用一个方法，错误可能是模型或者帮助文件中发生的。此时就该深入到栈跟踪来看，栈顶一行显示了是哪行代码抛出了异常。接下来的一行显示的是哪行代码调用了这个错误的方法。以此类推，直至栈底，一般在dispatcher.rb这儿结束，因为这儿是Rails请求的入口。整个栈跟踪从定至底显示了错误发生的经过。 

百分之九十的情况，在应用跟踪的第一行就会直接告诉你存在bug的源代码，但是如果没有，从应用跟踪给出的有用信息，顺藤摸瓜，通过应用程序的逻辑来猜测bug发生的地方。