[rspec-devel] [Proposed Refactoring] - Current ExampleSpace class subclasses

[Jim Deville]

On Aug 21, 2007, at 11:18 PM, Scott Taylor wrote:

>
> On Aug 22, 2007, at 12:59 AM, David Chelimsky wrote:
>
>> On 8/21/07, Jim Deville <james.deville at gmail.com> wrote:
>>>
>>>>
>>>>>>> It would be kinda nice if there were a good plugin architecture
>>>>>>> to either
>>>>>>> Test::Unit or Rspec.
>>>>
>>>> That's a really good idea---my work colleagues and I could make our
>>>> current hacks a little more future-proof, and the folks who (for
>>>> some
>>>> reason) like Test::Unit can find a way to make the two play nicely
>>>> together.
>>>>
>>>
>>> I just wish I knew more about both projects internals to do  
>>> something
>>> about it. Still might be worth a try, though.
>>>
>>>> I guess I just don't understand the recent rash of "we're  
>>>> abandoning
>>>> RSpec" or "we're coding the next great RSpec alternative" blog
>>>> posts.
>>>> I suppose software inevitably runs into things it just can't do  
>>>> well
>>>> as its user base increases.
>>>>
>>>
>>> For me, I am a big supporter of RSpec and BDD, but I have trouble
>>> explaining why I like it so much more than Test::Unit to other
>>> people. I also have a co-worker who doubts the benefits of using
>>> mocks to isolate the tests.
>>
>> Mocking has been around a lot longer than BDD and there is a  
>> wealth of
>> literature on why mocking is good and why, to those who think so, it
>> is bad.
>>
>>> He mainly wonders why we are duplicating
>>> our effort by doing Unit tests and Integration tests.
>
> One of the real advantages to having a "test" suite is refactoring.
> The test suite allows you to sleep at night.  And if your integration
> tests (alone) cover 100% of the code (go ahead - run rcov on your
> integration tests), then those granular tests are a waste.  Getting
> your integration tests to cover 100% of the code on any non-trivial
> project seems simple enough - until you realize that the complexity
> is incredibly enormous (I'm thinking of the simplicity of Zeno
> catching up with the tortoise).
>
> So if you are thinking it of testing - then sure, some of it is
> duplication, but most of it is testing the incredible complexity in
> your system which would be nearly impossible to express in a high
> level customer-story/integration test.  This is only further
> magnified by the lack of a type system in Ruby.
>
>
> More relevant speak, but I'm too tired to connect it:
>
> Having just acquired a new rails project, with something like 30
> models and 30 controllers, I've really just learned one of the
> biggest benefits of TDD - and that is documentation - not just for
> domain experts, but future coders who are going to work on YOUR
> complex system.  In a way, you could think of specs (or unit tests)
> as the best comments possible.  Normal Comments can lie (and will, as
> the system changes), but executable specs never can.  Integrations
> tests are good for testing the system - but they aren't going to give
> you examples of how the objects interact on a more granular level.
> But they too, can serve as high level comments (or specifications)
> for what the system can do (usually more for the non-hacker).
>
> If the only benefit your receiving from this process is a good night
> sleep (i.e. testing) - then it certainly is a waste to "duplicate"
> these things.  But the BDD side of things is to treat these "tests"
> as just an extra added benefit (like finding a twenty dollar bill
> under your couch).  Hey - look at that!  I've designed an
> understandable system (the real benefit of BDD/TDD) - and it just
> happens to be nearly bug free (the "testing" involved)!
>

That is a really good point. Thanks.
>>
>> The really difficult thing to get across about mocking, and about TDD
>> in general, is that it is a process, not an end result.
>
> +1, but:
>
> Certainly not a silver bullet : ) , although I do think it is a great
> process to have - and one I wouldn't live without - just like I'd
> refuse to work on a project where the other developers didn't use
> version control.
>
> Scott
>
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel