On Mon, Feb 16, 2009 at 8:03 AM, Jan Lehnardt <[email protected]> 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? > > Cheers > Jan > -- > >
Throwing in my hat for the current direction things are heading: Private API tested inline Public API tested separately Use your brain to decide when to break that. HTH, Paul Davis
