Re: [PhillyOnRails] rspec slides

[Cassius Rosenthal <cassius@xmodulation.com>]

Toby DiPasquale wrote:
> On Thu, Sep 13, 2007 at 12:26:16PM -0400, Cassius Rosenthal wrote:
>   
> > > > * slows development for experienced coders
> > > >         
> > > Writing tests may add marginal more time to the initial coding but 
> > > saves mountains of time squashing bugs later.
> > >       
> > I don't think the time added is marginal.  As Aaron Mulder points out in 
> > his comment earlier in this thread, it depends on the project.  With 
> > multiple coders working over a significant development period, the time 
> > added for 'good' specs approaches marginal.  With a small number of 
> > programmers working on a quick app, experienced coders would do better 
> > to just write the implementation, and reserve specs for unusual models 
> > and logic.  Otherwise they will get caught in copy/past hell, 
> > maintaining trivial agreement between the specs and the implementation.
> >     
>
> Again, not to be a dick, but exactly how much BDD have you done with RSpec
> or similar? How big is your team and codebase? Are these statements
> opinion or your experience?
>   

I have written 5 apps using the BDD/RSpec approach from get-go, 
including the one that I wrote for the presentation.  3 of the 5 have 
what would be considered incomplete spec coverage, because we knew what 
we were doing and did not keep the specs for restful routes, nor did we 
test the Rails validation helpers.  Just as it is frowned upon to rspec 
whether ActiveRecord can save a record, I think it's equally pointless 
to rspec whether validates_length_of can return an error.

I have also written a rather sophisticated online business simulation 
used by two of the top-ten pharmaceutical companies, which began prior 
to RSpec and hence was written without BDD.  So I have the experience to 
speak to small teams and small-to-medium code bases used from personal 
to enterprise applications.  You can take this quote as an opinion 
backed by some real-world experience: "With a small number of 
programmers working on a quick app, experienced coders would do better 
to just write the implementation, and reserve specs for unusual models 
and logic."

The largest application that I am currently working on has a distributed 
network of coders.  In this case, RSpec is not an option because of the 
learning curve for a few of the other coders.  So while I am allowing 
that in the best case, large teams working on a large code base would 
see the additional time added by RSpec approach marginal --because of 
the reduction in bugs to offset the additional code-- I have not had the 
opportunity to test this.

So my experience suggests that RSpec is at least useful for unusual 
models and logic.  I am hypothesizing that fuller specs have a greater 
benefit for larger projects.  In both cases, I maintain that RSpec has 
many drawbacks including the ones that I listed previously, and people 
should be aware of them.

Cliff Moon wrote:
> As for BDD, my understanding is that the point of it is to make your
> tests into executable documentation.
I agree that this is one of the best things that RSpec has going for 
it.  Writing: "user.should have(4).dogs" feels very cool, and serves 
well for an API psuedo-documentation.

Steve Eichert wrote:
> It was mentioned that RSpec causes you to violate the DRY principal.  
> Do you think that violation is appropriate?
Yes; I think it is appropriate because that's the way RSpec was 
designed, and I'm appealing to everyone to accept it as a convention.  I 
wish it didn't work out that way, and I think it's going to be one of 
the most difficult aspects of RSpec to deal with, but I do not have a 
better solution.  I do think that helper modules will be abused.  
Getting the average Rails coder to switch gears between DRY 
implementation and RYO specing will be a hassle, but hopefully less of a 
hassle than cleaning up bugs.

Thanks!
-Casey
_______________________________________________
To unsubscribe or change your settings, visit:
http://lists.phillyonrails.org/mailman/listinfo/talk