On 16 Feb 2009, at 12:49, Robert Dionne wrote:
Take couch_btree for instance. It already has a test() function
which if you look closely exercises most of the public functions, so
one could readily put these in a separate module ( which I actually
did when I first started playing with runner) . However consider
chunkify or modify_node. I suppose one could have a separate
couch_btree_tests module that just includes couch_btree in order to
test these or one could export those functions. I'm not familiar
with Erlang internals to know if these approaches significantly
alter the code paths. How would you test something like chunkify?
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 the record, desk-sharing Alex (remember, my resident
TDD-guru :), would break the chunkify function out.)
In any event my point is only that you need to do both. I think the
EUnit folks intended this judging from the documentation[1].
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
lives, first. But we could make things a little more complex and make
the
test output verbose enough to show you what went wrong where.
Something like:
Testing Private APIs...passed.
Testing Public APIs...passed.
Testing HTTP API...passed.
But then, we could do it all inline. At the moment, this looks
like the most KISS solution. But we're doing ground-work
here and getting it right now is probably more important.
Another aspect is looooooooooooooooong files with loads
of unit-tests that are better broken up for easier handling :)
In any case, a good discussion, I think, keep it up!
Cheers
Jan
--
