> 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'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
