[rspec-users] When to use BDD/TDD w/ external libraries

David Chelimsky dchelimsky at gmail.com
Fri Jun 8 09:48:29 EDT 2007

On 6/8/07, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> On 6/8/07, Scott Taylor <mailing_lists at railsnewbie.com> wrote:
> >
> > Test First Development is great...But should you use it when you are
> > adding classes/methods on to external library that doesn't have an
> > extensive test suite?  I noticed that the rspec plugin for autotest
> > has no specs.
> >
> > David Chemlinsky said something to the list a while back that has
> > been stewing in my subconscious - that you develop software
> > differently using Test First Development/BDD.  I noticed that it
> David (Chelimsky is his last name) and Ryan Davis paired on the RSpec
> plugin for Autotest at Railsconf, and I suspect that "they didn't have
> time" to write specs for it ;-)
> Look at the number of bugs that have been reported (and fixed) against
> RSpec's Autotest plugin in the previous weeks.
> Maybe there is a relationship between the number of bugs and the lack
> of specs? ;-)


> > would be very hard to add a spec library to autotest (I once
> > performed some code coverage on it and I believe it was at something
> > like 30 or 40 percent.).  So if one wanted to develop something like
> > the rspec plugin to autotest, would it be wise to develop it test first?

Absolutely. TDD allows for the process that Ryan and I went through
but I skipped an important step because I was excited to get it out
the door. You're allowed to hack stuff together to figure out how it
works. But you're then supposed to throw all of that code out and
start over, test first. I failed to take this step :(

That said, I think that most of the bugs that have been reported
wouldn't have been tested against anyhow - they've mostly been due to
conflicts between varying versions of spec.opts and file loading
issues that I never saw happen and therefore wouldn't have likely
considered to describe.

This is part of the nature of TDD. TDD didn't evolve in one or
two-man, all-developer shops. It evolved on teams that included
testers. The goal was never for the tests to serve as tests as far as
the customer was concerned. It was about design. It was about
documentation. It was about making the job of the tester (the official
tester w/ the title and all) easier by reducing the number of bugs
they had to deal with. This meant that they could focus more on the
really important stuff instead of getting hung up on the trivial stuff
that *should* have been caught during development. This helped to
reduce the thrashing that often occurred once you reached the testing

That's part of why BDD came to be - to help put the focus back in the
right places: developers develop, testers test.

In the end, even the most disciplined TDD'er is only going to write
examples for the things he/she thinks of. You still should have a
tester on your team. The person who lives and breathes breaking code,
rather than developing code. We don't have a person like that on the
RSpec team. Well, actually, we DO have that. It's all of you! Which
means, really, we shouldn't be making major releases without release
candidates. I think RC is open source's informal means of exploratory

> Any code that doesn't have automated tests works by accident as far as
> I'm concerned.
> It makes no difference whether the code is using a third party library
> or code whether it's part of your own code.
> However, some third party libraries (like J2EE) makes it so hard to
> test any code using it that you essentially have to choose between the
> third party or the ability to test. Sometimes having both is too much
> work.

In terms of rspec and autotest, I think we're somewhere in the middle
here. Scott points out 30-40% coverage on autotest. There's a school
of thought in TDD that says "test your own code," implying that you
don't test 3rd party libraries. You test that your code interacts w/
the 3rd party code per the published API, but you either trust that
the 3rd party code works or you either accept the possibility of bugs
because the benefits are worth it or you don't use it.

For me, autotest has been great. There have been some integration
problems w/ rspec but while they've been annoying they haven't
instilled fear in me that I'm getting the wrong feedback. So I put up
with it.

But we could certainly get some tests around the existing integration
points: The test-to-file mappings, the command that gets generated,
etc. Patches welcome!


> Aslak
> > I'm not sure if anyone else has had this difficulty, or if I'm being
> > clear.  Let me know if I should clarify with some examples.
> >
> > Best,
> >
> > Scott
> >
> > _______________________________________________
> > rspec-users mailing list
> > rspec-users at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-users
> >
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

More information about the rspec-users mailing list