[MacRuby-devel] HotCocoa Part I

[Eloy Duran]

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.

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.

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

(Which brings me to subject of SCM ;-), as you know I'd love to see a  
move to git and possibly github.)

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

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.

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

- Eloy