On Feb 16, 2009, at 8:03 AM, Jan Lehnardt wrote:
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?
+1 (if I get a vote :)
I agree completely. As I count the files in src/couchdb (32 and
growing) I think it's a good time to start this, even if new tests
are only added opportunistically as bugs are fixed, etc... When 1.0
comes along and larger new features added these will serve us well.
Danke vielmals!
Cheers
Jan
--
