[Opensim-dev] Restructuring test directories

[Melanie]

Hi,

yes. That is the idea. Just please no compiling the tests into the 
same assembly. People do use debug builds to run actual regions.

Melanie


Stefan Andersson wrote:
> Ok, not opening up for discussion, just telling you what I've known to pragmatically work in microsoft c# projects;
>  
> * The assembly name _is_ the directory name (not a subtree)
>  
> So, you have the OpenSim.Framework.Communications dir and the OpenSim.Framework.Console as directories alongside each others
>  
> * The test assembly is called "*.Tests" and is placed in the same directory as the tested assembly
> this means that a listing of that dir would look like this:
>  
> OpenSim.Framework.Communications/
> OpenSim.Framework.Communications.Tests/
> OpenSim.Framework.Console/
> OpenSim.Framework.Console.Tests/
> and, incidentally, this is replicated in the solutions explorer.
>  
> which is what I mean with 'keeping them together'. Best regards,Stefan AnderssonTribal Media AB Join the 3d web revolution : http://tribalnet.se/ 
> 
> 
> 
>> Date: Mon, 8 Sep 2008 20:40:21 +1200> From: mariusz at nowostawski.org> To: opensim-dev at lists.berlios.de> Subject: Re: [Opensim-dev] Restructuring test directories> > > 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 le
vel 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 > execulable
s 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> > _______________________________________________> Opensim-dev mailing list> Opensim-dev at lists.berlios.de> https://lists.berlios.de/mailman/listinfo/opensim-dev
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev