[Opensim-dev] Restructuring test directories

[Mariusz Nowostawski]

Dr Scofield wrote:
> Mike Mazur wrote:
>   
>> Hi,
>>
>> On Fri, Sep 5, 2008 at 11:45 PM, Melanie <melanie at t-data.com> wrote:
>>     
>>> IMHO, the tests belong in separate DLLs.
>>>       
>> I'm kind of with Melanie here. Why force the production DLLs to larger
>> sizes when those tests are never run against the same compiled
>> assembly more than once? Also when packaging OpenSim, the test DLLs
>> can be removed, saving a little on space.
>>
>> -1 on combining code and its tests in one assembly.
>>
>>     
>
> i think having a.b.c.test and having test and code in different assemblies is
> not contradictory...
>   

I agree with Melanie et al that having test code + dependencies in the 
production level-executables is not desirable. The production 
executables should be lean and clean.

But, debug level executables and DLLs is a different story. I agree with 
those voices that having code and test cases for that code spread around 
in large number of directory structures and (often ad hoc, confusing and 
inconsistent) naming conventions, with large number of DLLs is not 
helpful for debugging and testing purposes. If I have a given DLL how I 
should know which DLL to call to test that one in question?  For a given 
test code how I know what code it is actually being tested? And for the 
code, how I know if there are test cases for it already or not?  Even 
though there is not much being tested in OS now, it is already confusing 
to know of what exactly is being tested, where the tests are, and which 
DLLs those tests are going to be compiled into.

The two objectives above are not exclusive - they can be achieved 
together. This is exactly what compile-time flags are for. This is why 
GCC has a -d flag, etc. The build process should produce clean 
execulables and DLLs for production releases, and debug executables and 
DLLs for everything else.

I would rather see test code being together with the code that is being 
tested, and I would rather see test binary code going into the DLL that 
is being tested too. There are some cases where a single test case spans 
multiple codebases, but these are usually exceptions, and could go to a 
single project-wide DLL with all the awkward tests - a DLL that is well 
known to everyone.

Otherwise, too much freedom will create more problems than necessary. 
Simple question like: "where is the test code for this particular code 
I'm looking at right now, and how I can run it" will become non-trivial.


-- 
cheers
Mariusz