You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by Jan Lehnardt <ja...@apache.org> on 2009/02/10 17:52:25 UTC
Eunit
Hi,
the previously mentioned stats patch introduces EUnit*-style unit
tests for Erlang code. I believe this is useful for the rest of CouchDB
as well. There is a simple test runner in test/ that includes a few
tests for the couch_config* modules but that was never meant to
be a permanent solution.
* http://svn.process-one.net/contribs/trunk/eunit/doc/overview-summary.html
EUnit is the de-facto unit testing tool for Erlang applications and
it is even included in the latest distributions of Erlang/OTP. It's
far from perfect, but I think CouchDB would benefit from adapting
it, to gain and encourage writing standardized test cases for
CouchDB modules.
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?
Technically, the EUnit tests for each module can be in the same
file as the module's functions or in a separate directory. I'd opt
for separating tests into their on directory, but I don't feel strongly
about it.
The tests should not interfere with production code. For this reason,
there is a compile-time switch to enable tests. We can wire this up
to `make test` so that EUnit-enabled CouchDB modules are built
locally and then tested. For `make install`, the compile-time switch
to enable tests would be off.
Some modules have a few tests inline, once we would have the
EUnit infrastructure in place, it'd be a good idea to modify the
existing
test to fit in.
Permitted that there are no licensing issues, is there anything that
would speak against adding EUnit tests to CouchDB?
--
For now, the EUnit patch is entangled in the statistics patch, but
we could separate that into its own. Would that be something that
the community is interested in? Also, somebody please clear the
legal issue :)
Cheers
Jan
--
Re: Eunit
Posted by Jan Lehnardt <ja...@apache.org>.
Hi Micheal,
On 10 Feb 2009, at 19:29, Michael McDaniel wrote:
>>
>> 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 don't want to complicate the proposed patches. I'm not for
or against this, but we should think about that separately.
Maybe open a JIRA ticket so we don't forget about this that
includes a short description of the benefits?
> [...]
>
> 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 ...
Since we're using good old make, this would look a little different
in practice, but would do the same thing :)
Thanks for chiming and the tips.
Cheers
Jan
--
Re: Eunit
Posted by Michael McDaniel <co...@autosys.us>.
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 <ja...@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
Re: Eunit
Posted by Jan Lehnardt <ja...@apache.org>.
On 10 Feb 2009, at 18:11, Gianugo Rabellino wrote:
> On Tue, Feb 10, 2009 at 5:52 PM, Jan Lehnardt <ja...@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
--
Re: Eunit
Posted by Gianugo Rabellino <gi...@gmail.com>.
On Tue, Feb 10, 2009 at 5:52 PM, Jan Lehnardt <ja...@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?).
--
Gianugo Rabellino
Sourcesense, making sense of Open Source: http://www.sourcesense.com
(blogging at http://www.rabellino.it/blog/)