[MacRuby-devel] HotCocoa Part I

[Laurent Sansonetti]

On Dec 3, 2008, at 2:56 AM, Eloy Duran wrote:
> On Dec 3, 2008, at 11:26 AM, Laurent Sansonetti wrote:
>> On Dec 3, 2008, at 2:09 AM, Eloy Duran wrote:
>>
>>> Hi Laurent,
>>>
>>>> I agree HotCocoa should be covered by tests, at least to catch  
>>>> regressions.
>>>>
>>>> HotCocoa was initially started as an experiment and we (well,  
>>>> Rich) iterated a lot on the interface, now it's maybe time to  
>>>> start thinking about freezing some parts of the API (most  
>>>> probably the mappings) and covering these with tests would be a  
>>>> good idea.
>>>
>>> Right, that's fair enough :)
>>>
>>>> I think that most contributions will be mapping files.
>>>
>>> I too think that most contribution will be mappings,
>>> but we should invite people to be able to do more than that though  
>>> if they want to.
>>>
>>>>> So I would vote for rewriting HotCocoa in a TDD manner,
>>>>> which isn't too hard with the majority of the functionality  
>>>>> already fleshed out.
>>>>
>>>> I disagree on this point, why would you want to rewrite the  
>>>> existing code instead of just covering it with tests? This sounds  
>>>> like a bad idea to me.
>>>>
>>>> I know this violates the TDD principle but we could simply make  
>>>> sure the already-written functionality is covered with tests.
>>>
>>> Well that's why it violates the TDD principle. If you are going to  
>>> write tests afterwards, you _will_ leave gaps,
>>> which will introduce regressions sooner or later.
>>
>> There exists code coverage tools to make sure you don't leave gaps.  
>> Depends how far the gap is, I guess.
>
> Yeah, tools like RCov can't be trusted blindly. I will simply see if  
> all code has been ran, not whether or not you tested all different  
> situations.
>
>> Keep in mind that not every one on earth believes in TDD :-)
>
> I do, that's why I'm making this case especially for HotCocoa and  
> not for core MacRuby.
> And it's not really a question of “believing”, TDD is testing done  
> right™. I assume everybody cares about that.

I am a strong proponent of covering significant code paths with tests  
to make sure they do not regress, as well as associating every  
important bug fix with a test. But I don't believe in writing tests  
before every single code change, which is what TDD is all about  
AFAIK.  This is resource consuming and at the end of the day you spend  
most of your time writing/maintaining your tests. I tried TDD in the  
past for a couple of (light) projects and it did not work well for me,  
but maybe I did it wrong and/or I'm an exception :-)

Laurent