[MacRuby-devel] HotCocoa Part I

Laurent Sansonetti lsansonetti at apple.com
Wed Dec 3 02:26:45 PST 2008


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.

Keep in mind that not every one on earth believes in TDD :-)

> 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.)

>> 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.

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 :-)

> 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.

> 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.

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

Indeed :-)

Laurent


More information about the MacRuby-devel mailing list