关于测试
测试思维
我们不必过于关注 TDD、BDD、DDD 等名词。这些名词对写测试的帮助不大，反而会把原本简单的事情复杂化。写测试的关键是要保持简单。只有简单的测试代码才能测试简单的代码。简单来说，代码必须易于测试，不易测试的代码需要进行重构，使其易于测试。
TDD 提倡的测试驱动开发对我来说难以实现，因为有时候我自己都不知道代码写好后会变成什么样子。单纯的输入输出很难决定代码中间所经历的过程。另一个重要点是被测试代码的粒度越小越好，这意味着模块化程度越高，接口定义也越干净，这是非常值得的。因此，不要过多纠结于 BDD、TDD、DDD 这些名词，专注于写测试代码，并尽可能扩大测试覆盖面才是最重要的。
RSpec的问题
RSpec 定义了测试的领域特定语言，目的是让非开发人员也能写测试。这个目标很美好，想法也很好。但实际上，我们很难在项目中找到一个会写测试的测试工程师。没有开发能力，很难写好 RSpec。因此，让非开发人员写测试代码只是一个美好的想法，测试代码还是得由你自己来写，因为你对自己写的模块最了解。
相比之下，Rails 自带的测试框架已经很不错了，模块化分析测试很好地控制了测试的粒度。而且它非常快，运行所有测试的速度比 RSpec 快很多，这一点很重要。RSpec 的性能问题常被诟病，因为它会增加对写测试代码的厌恶。一个简单的测试用例要跑 10 秒，这严重影响了写代码的体验。
测试的作用
修改代码比写新代码要复杂，需要小心应对以前的历史包袱，还要了解以前的工作机制。所以，有一些现成的测试用例代码能很好地应对这些问题。它能保证你不会对以前的代码产生副作用，并且在编写测试代码阶段可以让你对接口的合理性进行更详细的检查，从而提高代码质量。
在项目部署前运行所有的测试用例可以让人安心不少，尽管部署时出现的问题大多集中在恶劣的服务器环境上。
References