似乎有两种完全不同的测试方法，我想引用这两种方法.
问题是，这些观点是在5年前(2007年)提出的，我很感兴趣，从那时起发生了什么变化，我应该走哪条路.
理论上，测试应该是不可知的
有了RSpec，我觉得这是完全嘲笑你的
这本身并不是太糟糕，但问题是它也有同龄人
当您有嵌套的资源并且
RSpec的目的是将控制器逻辑与
那么BDD想要做什么呢？退后一步，我的行为
大卫·切里姆斯基:
这一切都是为了取舍.
AR Select 继承而非授权的事实让我们陷入了困境
为了解决这个难题，我 Select 了更快的测试，代价是
在实践中，我一天运行数百次测试，如果不是数千次的话
但如果你的方法在实践中对你有用，那就好了！在里面
出于好奇，您在测试/规格中使用模拟的频率是多少？
在过go 的几个小时里，我几乎从我的规格中删除了所有的模拟.
我认为这三种观点仍然完全正确.Ryan和我都在努力解决mocking的可维护性问题，而David觉得为了提高速度，维护折衷是值得的.
但这些权衡是大卫在2007年提到的一个更深层次问题的症状:ActiveRecord.ActiveRecord的设计鼓励您创建一些功能过多、对系统其他部分了解过多、表面积过大的god对象.这导致测试需要测试的内容太多，对系统的其他部分了解太多，并且要么太慢，要么太脆弱.
那么解决方案是什么呢？将尽可能多的应用程序与框架分离.编写许多小型类，对你的域进行建模，不从任何东西继承.每个对象都应该有有限的表面积(不超过几个方法)和通过构造函数传递的显式依赖项.
使用这种方法，我只编写了两种类型的测试:独立单元测试和完整堆栈系统测试.在隔离测试中，我模拟或存根所有不是测试对象的东西.这些测试速度非常快，通常甚至不需要加载整个Rails环境.完整的堆栈测试将运行整个系统.他们的速度非常慢，失败时会给出无用的反馈.我尽可能少地写，但足以让我相信所有经过良好测试的对象都能很好地集成.
不幸的是，我还不能给你们指出一个做得很好的范例项目.我在Why Our Code Smells的演讲中谈到了这一点，观看了科里·海恩斯在Fast Rails Tests的演讲，我强烈推荐阅读Growing Object Oriented Software Guided by Tests.