On Jul 22, 2010, at 10:48 AM, ericindc wrote: > I'm unsure why this test is still failing. I've tested it in console > and the code works as expected. Is there something wrong with how I > have my test written? > > ****************** error > > 1) Job selecting the next job to be processed should lock the next job > Failure/Error: job.should_receive(:update_attribute).with(:locked, > true) > (#<Job:0x105496488>).update_attribute(:locked, true) > expected: 1 time > received: 0 times > > > ****************** job_spec.rb > > it "should lock the next job" do > job = Factory(:job, :locked => false) > job.should_receive(:update_attribute).with(:locked, true) > Job.next > end > > > ****************** job.rb > > def self.next > job = incomplete.unlocked.prioritized.limit(1).first
This job object is not the same object as the on in the spec. To get this to work, you'd have to stub like so: Job.stub_chain(:incomplete, :unlocked, :prioritized, :limit).and_return(job) Personally, I wouldn't bother, especially since you're using a real db backed object anyhow (Factory(:job ...)). I'd just write the spec like this: job = Factory(:job, :locked => false) job.next job.should_not be_locked Much cleaner and to the point, and less invasive (and therefore less brittle). HTH, David > job.lock! if job > job > end > > def lock! > update_attribute(:locked, true) > end > > def unlock! > update_attribute(:locked, false) > end > _______________________________________________ > rspec-users mailing list > [email protected] > http://rubyforge.org/mailman/listinfo/rspec-users _______________________________________________ rspec-users mailing list [email protected] http://rubyforge.org/mailman/listinfo/rspec-users
