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 <[email protected]> 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 [email protected]. 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
