On 8/24/07, Pat Maddox <[EMAIL PROTECTED]> wrote: > On 8/24/07, David Chelimsky <[EMAIL PROTECTED]> wrote: > > On 8/24/07, Pat Maddox <[EMAIL PROTECTED]> wrote: > > > On 8/24/07, David Chelimsky <[EMAIL PROTECTED]> wrote: > > > > describe Widget, "class" do > > > > it "should provide a list of widgets sorted alphabetically" do > > > > Widget.should_receive(:find).with(:order => "name ASC") > > > > Widget.find_alphabetically > > > > end > > > > end > > > > > > > > You're correct that the refactoring requires you to change the > > > > object-level examples, and that is something that would be nice to > > > > avoid. But also keep in mind that in java and C# people refactor > > > > things like that all the time without batting an eye, because the > > > > tools make it a one-step activity. Refactoring is changing the design > > > > of your *system* without changing its behaviour. That doesn't really > > > > fly all the way down to the object level 100% of the time. > > > > > > > > WDYT? > > > > > > I think that example is fine up until the model spec. The > > > find_alphabetically example should hit the db, imo. With the current > > > spec there's no way to know whether find_alphabetically actually works > > > or not. You're relying on knowledge of ActiveRecord here, trusting > > > that the arguments to find are correct. > > > > Au contrare! This all starts with an Integration Test. I didn't post > > the code but I did mention it. > > You're absolutely right, there should be an integration or acceptance > test that exercises the behavior. I would question then whether or > not the example for find_alphabetically is (a) pulling its weight or > (b) too brittle. > > (a) What value does the example provide? It doesn't serve to document > how find_alphabetically is used (usage doco is provided by good > naming, and secondarily by the controller specs). It doesn't give you > any information that you couldn't get by looking at the > implementation, because it duplicates the implementation exactly. So > the only real benefits of it is that you can see it when you visually > scan the specs, and it shows up in the output when you generate spec > docs. > > Those are real benefits, of course, which leads me to believe that the > spec is just a bit brittle. Knowing what exact arguments are passed > to Widget.find doesn't add any value. It makes the test more > cluttered and brittle. All we really care about is that a find is > performed. In that case, perhaps the example should be simply > > it "should provide a list of widgets sorted alphabetically" do > Widget.should_receive(:find) > Widget.find_alphabetically > end > > WDYT?
The problem w/ that, for me, is that if I change that method for any reason I won't know if I broke anything until I run the integration tests. I'll trade off a bit of brittleness for rapid feedback. Not always - but usually. > > > I play this both ways and haven't come to a preference, but I'm > > leaning towards blocking database access from the rspec examples and > > only allowing it my end to end tests (using Rails Integration Tests or > > - soon - RSpec's new Story Runner). > > Will Story Runner give us all the same abilities as Rails ITs, > obviating the need for test::unit altogether? Yes. Just need to figure out how to wrap IT w/ Story Runner. Cheers, David > > Pat > _______________________________________________ > rspec-users mailing list > rspec-users@rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users > _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
