Cassius Rosenthal on 13 Sep 2007 19:22:33 -0000

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: [PhillyOnRails] rspec slides

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.

To unsubscribe or change your settings, visit: