[MacRuby-devel] HotCocoa Part I

[Eloy Duran]

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.

>> Also, I don't think that trying to write tests for existing code  
>> vs. rewriting,
>> with an existing impl. as a regression test, will take that much  
>> less time.
>> The existing code will be used for this though, don't think I mean  
>> throw
>> away and don't look at it. I just don't believe in good coverage by  
>> simply adding tests.
>>
>> I mean, HotCocoa is still young, this is the ideal time to take  
>> such a decision without
>> it taking too much of an effort. And it will greatly benefit the  
>> user contribution/stability in the future.
>
> Agreed, if we have to make such a decision it's the ideal time.
>
> Since Rich is the main person behind the project we should leave  
> this decision to him.
>
>>>> I know I'm quite alone on the stance about TDD etc on this list,  
>>>> so I need to put my money where my mouth is.
>>>> Thus I have started experimenting with mspec (since we'll need it  
>>>> anyways) and rewrote some parts of HotCocoa.
>>>> However this was purely "playing" time, meaning I'll throw away  
>>>> that code and start again now that
>>>> I have some experience with all code involved.
>>>>
>>>> After that would come a testing facility for HotCocoa apps.
>>>> Which I would probably create in a manner to work with both  
>>>> Rucola and HotCocoa.
>>>> (Probably by re-using some stuff of Rucola::TestCase.)
>>>>
>>>> I expect to really start work at this and committing the end of  
>>>> this week/next week.
>>>> So there's plenty of time left for discussion on this topic.
>>>
>>> While this is all interesting, please do not commit anything to  
>>> trunk before we discuss this idea together.
>>
>> Sorry, I said it the wrong way around. What I meant was let's  
>> discuss before I start working on it.
>> I wouldn't start to commit (possibly) broken code to trunk. I will  
>> first work in a git branch.
>
> Excellent - you can create an SVN branch too if you like.
>
>> (Which brings me to subject of SCM ;-), as you know I'd love to see  
>> a move to git and possibly github.)
>
> I don't plan to move MacRuby to Git, not until I know how to use it  
> at least :-)
>
> (But I'm learning it right now, so please be patient.)

Yeah I know, I was teasing you ;-)

>>> Also, I am a bit suspicious when it comes to the rspec syntax. I  
>>> personally would prefer the shoulda or pure test/unit syntax.
>>
>> I personally would normally prefer using test/spec, because it's a  
>> layer on top of test/unit so you can mix the two. (shoulda is of  
>> course the alternative).
>> I was trying mspec because it's used by the rubyspec project, so we  
>> will need it anyways. (As I believe you said you'd want to start  
>> using that??)
>
> I said I would start to run the RubySpec project and contribute  
> missing 1.9/MacRuby specs to it. Since RubySpec uses the rspec  
> syntax I indeed need to adopt the same syntax for contributions.

Ok. Unfortunately the current situation of rubyspec with 1.9 would not  
be very usable to us. Since they have just started to write spec for  
the diff. between 1.8 and 1.9,
but there's no mechanism yet to run the rest of the 1.8 specs and only  
replace the specs that are different between the 2…
I don't follow their ML though, so they might have been discussing  
this issue.

> Here we are talking about covering our own code, so we can chose  
> which syntax we prefer. I'm not sure we all like the rspec syntax :-)

Again, shoulda etc is fine by me just not pure test/unit old-school  
style.
I'm not evangelizing spec style here specifically, just good tests  
which motivate others except the author.

>> But, like I said, I myself would prefer test/spec because of the  
>> test/unit compatibility.
>> Or as I understand, miniunit also contains a spec thing and will  
>> replace test/unit in 1.9 (is this 100% sure?)
>
> AFAIK it's not going to replace test/unit. But I did not follow this  
> closely enough recently to be sure.

Same here… :(

>> However, pure test/unit syntax, as you mean, does not encourage  
>> proper descriptions of the intended behaviour and so I think it  
>> should be avoided.
>>
>> There's a reason why the BDD guys tried so hard to get away from  
>> the word “testing” and rather use “specify” (or whatever they use  
>> nowadays).
>> It's because real test code is most of the times verbose and only  
>> clear in 1 sec to the author of the test.
>> That's not to say that the test didn't actually test what it  
>> should, it's simply un-useful as a spec/doc and doesn't encourage  
>> maintainability.
>
> Yeah, I read about BDD. I'm not convinced so far, as you know, but  
> I'm an old-school guy.

I know and understand. Please note that, like I said somewhat above, I  
don't care about evangelizing BDD or whatever.
What I _have_ noticed is that you need to adopt certain styles for  
more people to come in and see no problem in also maintaing tests for  
their code patches.

Yeah I know, you are hardcore, that's why I/we love you ;-)

>> Cheers Laurent,
>> always fun to have this discussion ;-)
>
> Indeed :-)

:-)

Eloy