Re: [E-devel] location of unit tests

2008-05-07 Thread Cedric BAIL
On Wed, May 7, 2008 at 6:29 AM, Vincent Torri <[EMAIL PROTECTED]> wrote:
>  raster, dan and me had a small discussion about the location of unit
>  tests. Dan and me were for putting them in efl_lib/tests and raster in
>  e17/tests/efl_lib
>
>  raster arguments are for putting them outside efl_lib/ are
>
>  1) lots of data in src/. Indeed, maybe big files can be needed. That can
>  increase the size of the tarball.
>  2) end users and packagers do not need them
>  3) if unit tests are in the tarball, packager can maybe think that they
>  must ship them.
>
>  raster: if you think that i have forgotten something, please add any
>  argument

I just want to raise some point regarding putting unit test inside the
released tarball. It should ease the work of a release manager, just
run make dist-check and if all the tests passed, you are ready for a
release. Another situation where it can help, is when someone compile
the library from source and has some problem, so we could just ask him
to run make check and send us the report. This should help developper
that use our lib by providing an easier learning path.

In any case, having unit test and coverage report will be really
helpfull, so as soon as everyone agreed on Vincent proposal, I am for
adding the necessary stuff to eet at least (but all efl libs should
have their own unit test, I think).

-- 
Cedric BAIL

-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


[E-devel] location of unit tests

2008-05-06 Thread Vincent Torri

Hey,

raster, dan and me had a small discussion about the location of unit 
tests. Dan and me were for putting them in efl_lib/tests and raster in 
e17/tests/efl_lib

raster arguments are for putting them outside efl_lib/ are

1) lots of data in src/. Indeed, maybe big files can be needed. That can 
increase the size of the tarball.
2) end users and packagers do not need them
3) if unit tests are in the tarball, packager can maybe think that they 
must ship them.

raster: if you think that i have forgotten something, please add any 
argument

Although I'm not sure that point 3) is really a problem (as lots of libs 
have unit tests, and i didn't see any packages related to these unit tests 
yet. But it's possible, of course), i think that there can be a solution:

a) I suppose that packages are done from a release tarball, and not from 
code that is in cvs. If i'm wrong, then my argument is null.

b) we put unit tests in cvs in efl_lib/tests

c) they are not compiled when running 'make'. We just have to use the 
'check_' prefix in Makefile.am's. They are run with 'make check'. Hence, 
when a release should be build or a code is modified, running 'make check' 
is sufficient.

d) About the size of the tarball, we can do something like that in 
efl_lib/tests/Makefile.am:

check_PROGRAMS = efl_lib_test
nodist_efl_lib_test_SOURCES = file1.c file2.c

hence:

* we can add any test file (images, .desktop file, etc...), they are not 
in the tarball because not listed in EXTRA_DIST

* source code for unit tests is not in tarball as they are prefixed by 
'nodist_'

that should solve all the points above. Of course, we have to run 'make 
check' to run the tests. 'make' is not sufficient. Also, if the end users
or packagers are using cvs code, they can have a big repo. But I suppose 
that if they choose to get source code from cvs, they know that they can 
find things they do not expect.

Is it a sufficiently good solution to pointds 1), 2) and 3) ? Am I missing 
something ?

Vincent

-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel