On Mon, Sep 15, 2008 at 4:14 PM, Tim Glen <[EMAIL PROTECTED]> wrote: > Hey all, > > I've got some code that I (mostly) inherited. It essentially has a couple of > AR class methods that look for a specific record by id: > > class Project < ActiveRecord::Base > class << self > def specific_project > @another_specific_project ||= Project.find(10) if Project.exists?(10) > end > > def another_specific_project > @specific_project ||= Project.find(11) if Project.exists?(11) > end > end > end > > Typically, when I've specced this code (or more accurately, code that uses > it), I've stubbed out those methods to return a mocked model. Lately, I've > started using cucumber and adding stories for areas we're adding features to > or finding regressions in. From what I can tell, I can't stub or mock > anything from within cucumber step files. Realizing that the pattern is a > bit of code smell, I feel like I have two directions I could go: > 1. Is there a way to stub out the model to return some fixture-type records?
I don't think you're really supposed to mock or stub when using cucumber. > 2. Does anyone have an idea as to how we could refactor this into a better > pattern? Those 2 "projects" are pretty specific to the production data and > will "never be edited," but it still doesn't make me comfortable. Maybe you could add a column that represents the unique characteristic of the particular projects. I'd probably end up with: def internal_project @internal_project ||= Project.find(:first, :conditions => "internal IS TRUE") end def demo_project @demo_project ||= Project.find(:first, :conditions => "demo IS TRUE") end or maybe have one column and let its value change: def internal_project @internal_project ||= Project.find(:first, :conditions => "role='internal'") end def demo_project @demo_project ||= Project.find(:first, :conditions => "role='demo'") end Pat _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
