couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael McDaniel <couc...@autosys.us>
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 <jan@apache.org> 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

     ../doc
     ../ebin
     ../include
     ../priv
     ../src
     ../test

 (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,

 http://www.nabble.com/I-Hate-Unit-Testing...-td21697138.html

 http://www.nabble.com/Lightweight-test-driven-development-and-unit-testing-td21704767.html

 
 e.g.

 %  the module to test

 -module(my_mod).
 -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

 -module(my_mod_test.erl).
 -ifdef(test).
 -include_lib("eunit/include/eunit.hrl").

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

   blah blah blah remaining tests

 -else.
 -endif.

% 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"}
       ,debug_info
       ,strict_record_tests
       ,netload
       , {d,debug}     %% uncomment for debug
       , {d,test}      %% uncomment for dev/test, do touch ../test/*
      ] 
 }.



~Michael

---
Portland, Oregon, USA
http://autosys.us

Mime
View raw message