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

Jonathan Linowes jonathan at parkerhill.com
Fri Jun 8 13:06:29 EDT 2007

most plugins come with their own rails tests

i've converted one by hand to rspec (restful_authentication) because
- its functionality is integral to my app
- its really a generator so the code ends up in my app
- there's a good chance i'll be making custom changes to it as my app  

perhaps a tool that automatically converts rails tests to rspecs  
would be useful?
obviously thats not TDD but it would give you the code coverage
and provide a starting point if you make custom changes to the plugin

On Jun 8, 2007, at 9:48 AM, David Chelimsky wrote:

> 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? ;-)
> Definitely.
>>> 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
> phase.
> 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
> testing.
>> 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!
> Cheers,
> David
>> 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
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

More information about the rspec-users mailing list