On 16 Feb 2009, at 13:37, Robert Dionne wrote:
Pure unit-test logic would suggest creating a couch_btree_chunker
module. Like how I did with couch_config and couch_config_writer.
But then, pragmatism will call heresy and I'd probably agree.
For sure, "In theory there's no difference between theory and
practice, but in practice there is" :)
The question is if we want to "do it right" now or KISS our way out of
this?
The only problem I see here is that tests belonging to a single
module
are run in different places and you'd have to track down where the
test
hmm... actually according to the docs if you run
eunit:test([couch_btree]) it does both (I haven't tested this yet).
In other words it ensures couch_btree:test() is run and also finds
and runs tests in couch_btree_tests. So if I read this correctly it
solve this issue, non?
You're right, I just tested this, nice.
Oh I see, it wouldn't tell you which ones failed?
No no, it does. All is well :)
I'd suggest we establish this guidelines for writing tests:
- A module's public API should be tested in a separate module as it
helps
refining the public API, keeps files at a manageable size and
changes
to either tests or the module don't interfere with each other
(plus all the
good thing Michael McDaniel pointed out earlier).
- A module's private API is tested using inline-tests.
- Large* modules should be considered for split-ups keep things more
manageable.
*Large is defined pragmatically on a case-by-case basis.
What do you think?
Cheers
Jan
--
