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 10:27:58 GMT
Hi Robert,

thanks for your feedback.

On 16 Feb 2009, at 03:42, Robert Dionne wrote:

> If I read the EUnits docs correctly you can do both, have them in  
> the files as well as in separate file. I believe if you run  
> eunit:test([some_module]) it will run both tests in the module as  
> well as look for some_module_tests and run those also.

Both is possible, my original version (from the stats patch)
used inline test code and this patch now uses external

> I think there are some modules where the amount of complexity among  
> all the private methods warrants tests in the modules, and others  
> where tests outside are more practical.

I was contemplating that as well. The stats code uses a record
to hold aggregate values. When testing the get() functions inline,
I could just make use of the already defined `-record()`. When
I moved the tests to a separate file, the record definition was
missing and I had to create a `couch_stats.hrl` file to include
the record in both places.

The stats module also takes care of converting the record to
the JSON-Erlang-term structure that gets send to the HTTP
handler. The public API never sees the record.

At first this seemed awkward to me as an implementation
detail spewed over to the test code. I then realized though,
that while the HTTP API never makes use of the record, it
is very much part of the public API of the stats module and it
is correct to explicitly import that part of the API into the test

Lesson learned: There is a CouchDB-public API that sends
JSON-Erlang-Terms to HTTP clients and a module-public
API that other parts of CouchDB can use.

Why this story: I think one basic premise* of unit testing is
testing only the public API of a module, the amount of
internal, private complexity is of no business to the test
code. And parts of the code in a module that should be
unit-tested while not being part of the module's public
API probably better live in a separate module. YMMV :)

* it's the very idea that you can swap out implementations
without breaking your API's contract.


View raw message