couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <>
Subject Re: [PATCH] Eunit Tests
Date Mon, 16 Feb 2009 13:03:44 GMT

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  

>> 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  
    refining the public API, keeps files at a manageable size and  
    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

*Large is defined pragmatically on a case-by-case basis.

What do you think?


View raw message