【问题标题】:rspec test failing: conflict between two "subjects"rspec 测试失败:两个“主题”之间的冲突
【发布时间】:2012-07-31 16:05:26
【问题描述】:

我无法通过考试。在我的应用程序中,用户可以拥有许多他们请求的会议 (sent_meetings) 和请求的会议 (received_meetings)。

首先,我的(简化的)user.rb 模型:

用户.rb

class User < ActiveRecord::Base
  attr_accessible :name, :email, :password, :password_confirmation
  has_secure_password

  has_many :sent_meetings, :foreign_key => "requestor_id", :class_name => "Meeting"
  has_many :received_meetings, :foreign_key => "requestee_id", :class_name => "Meeting"
end

还有我的 meeting.rb 模型:

会议.rb

class Meeting < ActiveRecord::Base
  attr_accessible :intro, :proposed_date, :proposed_location

  belongs_to :requestor, class_name: "User"
  belongs_to :requestee, class_name: "User"
end

我的测试:

meeting_spec.rb

require 'spec_helper'

describe Meeting do

  let(:requestee) { FactoryGirl.create(:user) }
  let(:requestor) { FactoryGirl.create(:user) }

  before { @received_meeting = requestee.received_meetings.build(intro: "Lorem ipsum") }
  before { @sent_meeting = requestor.sent_meetings.build(intro: "Lorem ipsum") }

  subject { @sent_meeting }
      it { should respond_to(:intro) }
      it { should respond_to(:requestor_id) }
      it { should respond_to(:requestor) }
      its(:requestor) { should == requestor }
      # it { should be_valid }

  subject { @received_meeting }
    it { should respond_to(:intro) }
    it { should respond_to(:requestee_id) }
    it { should respond_to(:requestee) }
    its(:requestee) { should == requestee }
    # it { should be_valid }

end

我的规范文件(@sent_meeting 和@received_meeting)中的两个“主题”行之间似乎存在冲突,并且其中一个覆盖了另一个。这是我失败的测试消息:

失败:

1) 会议请求者 失败/错误:其(:请求者){应该==请求者} 预期的: # 得到:无(使用==) # ./spec/models/meeting_spec.rb:15:in `block (2 levels) in '

在 0.67458 秒内完成 36 个示例,1 个失败

失败的例子:

rspec ./spec/models/meeting_spec.rb:15 # 会议请求者

我发现这个错误只发生在 either 请求者或被请求者(显然存在冲突),这很有趣。两个主题代码块的顺序很重要,当我切换它们时,我得到与上面相同的错误,但关于“requestee”而不是“requestor”。

我怎样才能让测试通过?谢谢!

【问题讨论】:

    标签: ruby-on-rails rspec


    【解决方案1】:

    你不能这样做。你必须这样做:

    require 'spec_helper'
    
    describe Meeting do
    
      let(:requestee) { FactoryGirl.create(:user) }
      let(:requestor) { FactoryGirl.create(:user) }
    
      before { @received_meeting = requestee.received_meetings.build(intro: "Lorem ipsum") }
      before { @sent_meeting = requestor.sent_meetings.build(intro: "Lorem ipsum") }
    
      describe "sent meetings" do
        subject { @sent_meeting }
        it { should respond_to(:intro) }
        it { should respond_to(:requestor_id) }
        it { should respond_to(:requestor) }
        its(:requestor) { should == requestor }
        it { should be_valid }
      end
    
      describe "received meetings" do
    
        subject { @received_meeting }
        it { should respond_to(:intro) }
        it { should respond_to(:requestee_id) }
        it { should respond_to(:requestee) }
        its(:requestee) { should == requestee }
        # it { should be_valid }
      end
    
    end
    

    你也可以像这样使用 let 代替:

    require 'spec_helper'
    
    describe Meeting do
    
      let(:requestee) { FactoryGirl.create(:user) }
      let(:requestor) { FactoryGirl.create(:user) }
      let(:received_meeting) { requestee.received_meetings.build(intro: "Lorem ipsum") }
      let(:sent_meeting) { requestor.sent_meetings.build(intro: "Lorem ipsum") }
    
      describe "sent meetings" do
        subject { sent_meeting }
        it { should respond_to(:intro) }
        it { should respond_to(:requestor_id) }
        it { should respond_to(:requestor) }
        its(:requestor) { should == requestor }
        it { should be_valid }
      end
    
      describe "received meetings" do
        subject { received_meeting }
        it { should respond_to(:intro) }
        it { should respond_to(:requestee_id) }
        it { should respond_to(:requestee) }
        its(:requestee) { should == requestee }
        it { should be_valid }
      end
    
    end
    

    会更快。

    【讨论】:

    • 太棒了,斗鬼。有用。谢谢!但是,现在我的验证测试失败了(我取消了'it { should be_valid }'的注释)。发送的会议和接收的会议是否都需要同时回复请求者和被请求者?我试过这个,但他们继续失败。
    • 我认为这是另一个问题。请批准我的回答并提出另一个问题。谢谢!
    猜你喜欢
    • 2023-03-03
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2011-10-09
    • 2019-06-30
    • 2014-05-11
    • 1970-01-01
    相关资源
    最近更新 更多