couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael McDaniel <>
Subject Re: Eunit
Date Tue, 10 Feb 2009 18:29:47 GMT
On Tue, Feb 10, 2009 at 06:19:01PM +0100, Jan Lehnardt wrote:
> On 10 Feb 2009, at 18:11, Gianugo Rabellino wrote:
>> On Tue, Feb 10, 2009 at 5:52 PM, Jan Lehnardt <> wrote:
>>> The one caveat with EUnit is that it is released under the LGPL.
>>> I am not a lawyer but the consensus on "The Net" is that writing
>>> test-cases against the EUnit API and conditionally including
>>> eunit.hrl to include the API does not mean that the test code itself
>>> must be released under the terms of the LGPL. If anyone is
>>> familiar with this, can you comment on whether this is correct?
>> Best for you would be to send a question to legal-discuss@a.o. With my
>> conservative hat on, I'm a bit concerned about LGPL virality in
>> namespaced languages, and most definitely concerned with distribution
>> of EUnit itself (I reckon this is not necessary as EUnit is part of
>> OTP now?).
> Thanks, I'll check with legal-discuss@ when this list agrees on adding
> EUnit support. Bundling EUnit is not necessary as of the latest OTP
> release and for earlier releases you need to install it manually or you
> can't run `make test` which is not too much of a problem, I'd say.
> Thanks
> Jan

 I am in agreement with adding EUnit support to CouchDB.

 I find EUnit useful when writing or changing code.

 Also, I support a separate test directory from the src


 (though I know CouchDB does not presently follow that OTP 
  recommended directory structure)

 I use EUnit in a simple manner based on a techniques derived
 from two erlang-questions threads,


 %  the module to test

 -export( [public_funs ...]  ).
 -include("../test/my_mod_test.erl").  % yes, .erl
  blah blah blah all the module funs both exported and private
% end of my_mod.erl

 and ...

 %  the testing module


 first_test()  -> ?assert( true = first_fun(arg) ).
 second_test() -> ?assert( {error, badarg} = second_fun(badarg) ).

   blah blah blah remaining tests


% end of my_mod_test.erl

 When compiling, simply do not -define( test ) and the my_mod_test
 module is not even included.  Note that this technique allows
 testing of private funs in my_mod without having to export the
 private funs.

 I also use Emakefile such as ...
 %% to make from command line do following
 %%    erl -make
 %% do not run tests from command line do following
 %%    erl -pa ../ebin -eval "eunit:test(my_mod, [verbose]), init:stop()."
 {'*', [
        {outdir, "../ebin"}
       ,{i, "../include"}
       ,{i, "../test"}
       , {d,debug}     %% uncomment for debug
       , {d,test}      %% uncomment for dev/test, do touch ../test/*


Portland, Oregon, USA

View raw message