我已经使用了一段时间,并且我已经阅读并使用了 rspec。我还没有进行深入的比较和对比。但在我看来,两者之间似乎有一些重叠,但它们不是 1-1 的替代品。
我正在考虑使用 rspec 在我的 rails 系统中编写一些单元测试,而不用替换所有使用 shoulda 编写的现有测试。只是作为一种感受的方式。
这是一个好主意吗?我可以逐渐从一个转移到另一个,还是我在自找麻烦?
我应该考虑一个比另一个明显的优势吗?
谢谢!
我已经使用了一段时间,并且我已经阅读并使用了 rspec。我还没有进行深入的比较和对比。但在我看来,两者之间似乎有一些重叠,但它们不是 1-1 的替代品。
我正在考虑使用 rspec 在我的 rails 系统中编写一些单元测试,而不用替换所有使用 shoulda 编写的现有测试。只是作为一种感受的方式。
这是一个好主意吗?我可以逐渐从一个转移到另一个,还是我在自找麻烦?
我应该考虑一个比另一个明显的优势吗?
谢谢!
我不得不反对克里斯的回答,即它们是替代品。我在我的 Rails 应用程序中同时使用了 Shoulda 和 Rspec,它们可以很好地互补。
这个组合让我可以编写简洁的单行单元测试,用于重复发生的事情,如关联和验证,以及为更复杂的规范提供完整的 rspec 套件。您可以在没有任何冲突的情况下获得两全其美。
查看展示了如何在 Rspec 旁边安装的Shoulda README 。它甚至说它提供了“Test::Unit 和 RSpec 兼容的单行程序,用于测试常见的 Rails 功能。否则这些测试会更长、更复杂且容易出错。”
编辑(示例):
在我的规范的顶部,我总是声明我的类关系和验证测试,它们简洁易读。
describe Component do
context 'relationships' do
it { should belong_to(:technology)}
it { should have_many(:system_components) }
it { should have_and_belong_to_many(:variables) }
it { should have_many(:images).dependent(:destroy) }
it { should have_many(:documents).dependent(:destroy) }
end
context 'validations' do
it { should validate_presence_of(:make) }
it { should validate_presence_of(:model) }
it { should ensure_length_of(:name).is_at_most(100) }
it { should validate_presence_of(:technology_id) }
end
end
然后我的规范的其余部分将有更复杂的测试,我使用来自 Rspec 的模拟和存根。
rspec 和 shoulda 是彼此的替代品。s/context/describe/
我也是从 shoulda 开始的,迁移到 rspec 就像,一样简单s/should/it/
,然后你就可以参加比赛了。rspec 有很多技巧、各种集成和更复杂的匹配器,所以这些天我自己更多地使用它。
我最初的挫败感之一是几乎不可能找到一个没有假设 Rails 和 Cucumber 的教程。不要想太多——你可以用它做很多事情,但在你使用它之前你不必有一个解决方案的怪物。