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
_______________________________________________
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
