【问题标题】:rspec and shoulda - complementary or alternatives?rspec 和 shoulda - 互补还是替代?
【发布时间】:2011-01-05 21:46:16
【问题描述】:

我用过 shoulda 有一段时间了,我也读过并玩过 rspec。我还没有进行深入的比较和对比。但在我看来,两者之间有一些重叠,但它们不是一对一的替代品。

我正在考虑使用 rspec 在我的 rails 系统中编写一些单元测试,而不是替换所有使用 shoulda 编写的现有测试。只是作为一种感受的方式。

这是个好主意吗?我可以逐渐从一个转移到另一个,还是我在自找麻烦?

我应该考虑其中一个相对于另一个的明显优势吗?

谢谢!

【问题讨论】:

    标签: ruby-on-rails ruby rspec shoulda


    【解决方案1】:

    我不得不反对克里斯的回答,即它们是替代品。我在我的 Rails 应用程序中同时使用了 Shoulda 和 Rspec,它们可以很好地互补。

    这个组合让我可以编写简洁的单行单元测试,用于重复发生的事情,如关联和验证,以及为更复杂的规范提供完整的 rspec 套件。您可以在没有任何冲突的情况下获得两全其美。

    查看Shoulda README,它显示了如何沿着 Rspec 安装。它甚至说它提供了“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 的模拟和存根。

    【讨论】:

    • 这里有一些关于它的更多观点:stackoverflow.com/questions/3604564/rspec-vs-shoulda
    • 我喜欢一些你用组合做的事情的例子,这些事情不能用一个或另一个来完成。如果有办法清理我的测试,我完全赞成。我一起使用 shoulda + matchy,然后发现 rspec 基本上做到了,然后从那里开始。仅仅是控制器匹配器之类的东西吗?
    • 我用一些我应该做的测试更新了我的答案。我倾向于遵循的一条规则是,Shouda 用于 Rails 的内置 Class 宏,如验证和关系,而 Rspec 用于需要模拟对象和方法存根的更复杂的测试。
    • +1 它们是免费的,至少在与 Rails 一起使用时是这样。让您执行it { should validate_presence_of(...) } 之类的操作。
    • @PaulFioravanti 我不测试那些。我只测试与行为相关的东西,我不考虑列或索引行为的存在。除非有人故意删除数据库列,否则它们不会消失,但是您可以通过代码审查和信任来防止这种情况发生:)
    【解决方案2】:

    rspec 和 shoulda 是彼此的替代品。我也是从 shoulda 开始的,迁移到 rspec 就像 s/context/describe/s/should/it/ 一样简单,然后你就可以参加比赛了。 rspec 有很多技巧,各种集成,以及更复杂的匹配器,所以这些天我自己更多地使用它。

    我最初的挫败感之一是几乎不可能找到一个不使用 Rails 和 Cucumber 的教程。不要想太多 - 你可以用它做很多事情,但在使用它之前你不必有一个解决方案的怪物。

    【讨论】:

      猜你喜欢
      • 2011-09-09
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2020-12-26
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多