On Sat, Jan 9, 2010 at 9:38 PM, Sean DeNigris <truste...@clipperadams.com>wrote:
> > window = stub('window', :title => "programming_ruby_1.9.pdf")
> > preview = stub('preview', :front_window => window)
> Perfect - so easy! Thanks.
>
> > If you have good high level specs with something like Cucumber or
> FitNesse,
> > this risk is diminished. You'll still have to change the example when the
> > internal structure of Preview changes, but you're less likely to get
> burned
> > by deploying code that passes its tests but doesn't work.
> This is something I've been going back and forth with a lot lately -
> how much implementation detail to allow to leak out into the examples/
> features. If I start using software other than Preview to read my
> eBooks, obviously all these examples will require reworking. The
> problem is magnified because I do have Cucumber tests that use the
> real Preview:
>
> Then /^I should see the pickaxe book$/ do
> front_preview_window = Appscript::app('System Events').processes
> ['Preview'].windows[1]
> Appscript::app('System Events').processes
> ['Preview'].frontmost.get.should be(true)
> front_preview_window.name.get.should =~ /programming_ruby_1.9.*
> \.pdf.*/
> end
>
> Now details about Preview appear in Cucumber and Rspec! I'm tempted
> to put an EBookViewer role in right off the bat (similar to what Matt
> sugested), and use it in both the features and examples, but I don't
> want to add too much complexity.
>
I think it's clear that there is already too much complexity in this case :)
I'd go with the wrapper. It should not be expensive to maintain, and it does
give you the freedom to change the dependencies, localizing the cost of that
change to a single object.
> I'm very interested in how other people handle external dependencies
> in features/examples...
>
> Thanks again!
>
> Sean
>
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
