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

[Jim Deville]

On Aug 21, 2007, at 9:59 PM, 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.
>

I've found some of that literature, and it seems to keep him at bay.  
The problem is, every time we break a feature, he blames it on the  
mocks.

  The real problem seems to be bad mocks, bad tests, or incomplete  
tests. I tend towards the later.

>> He mainly wonders why we are duplicating
>> our effort by doing Unit tests and Integration tests.
>
> The really difficult thing to get across about mocking, and about TDD
> in general, is that it is a process, not an end result. Duplication
> between Programmer Tests (what you're calling Unit Tests) and Customer
> Tests (what you're calling Integration Tests) is temporal - there are
> moments in time when there is duplication and then, because we're
> refactoring relentlessly, that duplication goes away. That's because
> when we're refactoring we're not changing the system requirements as
> expressed in the Customer Tests, but we are changing the granular
> requirements of individual objects, as expressed in the Programmer
> Tests.
>
> This all make sense?
>

I think so. I think his feeling is that since the Customer tests  
should break whenever the Programmer tests break, we should just use  
the Customer tests. I feel that there is valuable insight, due to the  
isolation of the tests, in the breakage's of the Programmer tests. I  
think they are usually more thorough.

I think I'll try to point him to Fowler's article and the BDD/TDD  
websites next time. Maybe they will be able to clarify the point of  
view you're making better than I can.

Thanks,
Jim

>
>> I am in the odd
>> position of being one of the most knowledgeble Ruby/RSpec coders at
>> my job, but I am the least experienced in OO Design, TDD/BDD and
>> Agile processes. I wonder if a little more push on the BDD ideas
>> would help build faith in the RSpec framework and techniques.
>>
>>> But for us, over a year after we started looking at this thing, the
>>> bloom is still firmly on the rose.
>>>
>>> --Ian
>>> _______________________________________________
>>> rspec-devel mailing list
>>> rspec-devel at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/rspec-devel
>>
>> Jim
>> _______________________________________________
>> rspec-devel mailing list
>> rspec-devel at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-devel
>>
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel