[Opensim-dev] Restructuring test directories

[Melanie]

Hi,

there is one major issue with that approach: the script engine 
components. It is just not ever possible to put tests and code into 
one dll, not even in debug mode.
Because it will just not work. It will cause huge dependency trees 
to be loaded into the script app domain, consuming all available 
memory with only a few scripts. That would force a choice on people 
like me: Either run release code, and lose the line number 
information in crash dumps, or run debug code and be severely 
limited in usability, to the point of total unfitness for purpose.

So, anything to do with scripting must have tests in separate DLLs.

Melanie


Mariusz Nowostawski wrote:
> 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.
> 
>