<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>Ok, not opening up for discussion, just telling you what I've known to pragmatically work in microsoft c# projects;<BR>
<BR>
* The assembly name _is_ the directory name (not a subtree)<BR>
<BR>
So, you have the OpenSim.Framework.Communications dir and the OpenSim.Framework.Console as directories alongside each others<BR>
<BR>
* The test assembly is called "*.Tests" and is placed in the same directory as the tested assembly<BR>
this means that a listing of that dir would look like this:<BR>
<BR>
OpenSim.Framework.Communications/<BR>
OpenSim.Framework.Communications.Tests/<BR>
OpenSim.Framework.Console/<BR><BR>
OpenSim.Framework.Console.Tests/<BR><BR>
and, incidentally, this is replicated in the solutions explorer.<BR>
<BR>
which is what I mean with 'keeping them together'.<BR> <BR>Best regards,<BR>Stefan Andersson<BR>Tribal Media AB<BR> <BR>Join the 3d web revolution : <A href="http://tribalnet.se/" target=_blank>http://tribalnet.se/</A><BR> <BR><BR><BR><BR>
<HR id=stopSpelling>
<BR>
> Date: Mon, 8 Sep 2008 20:40:21 +1200<BR>> From: mariusz@nowostawski.org<BR>> To: opensim-dev@lists.berlios.de<BR>> Subject: Re: [Opensim-dev] Restructuring test directories<BR>> <BR>> <BR>> Dr Scofield wrote:<BR>> > Mike Mazur wrote:<BR>> > <BR>> >> Hi,<BR>> >><BR>> >> On Fri, Sep 5, 2008 at 11:45 PM, Melanie <melanie@t-data.com> wrote:<BR>> >> <BR>> >>> IMHO, the tests belong in separate DLLs.<BR>> >>> <BR>> >> I'm kind of with Melanie here. Why force the production DLLs to larger<BR>> >> sizes when those tests are never run against the same compiled<BR>> >> assembly more than once? Also when packaging OpenSim, the test DLLs<BR>> >> can be removed, saving a little on space.<BR>> >><BR>> >> -1 on combining code and its tests in one assembly.<BR>> >><BR>> >> <BR>> ><BR>> > i think having a.b.c.test and having test and code in different assemblies is<BR>> > not contradictory...<BR>> > <BR>> <BR>> I agree with Melanie et al that having test code + dependencies in the <BR>> production level-executables is not desirable. The production <BR>> executables should be lean and clean.<BR>> <BR>> But, debug level executables and DLLs is a different story. I agree with <BR>> those voices that having code and test cases for that code spread around <BR>> in large number of directory structures and (often ad hoc, confusing and <BR>> inconsistent) naming conventions, with large number of DLLs is not <BR>> helpful for debugging and testing purposes. If I have a given DLL how I <BR>> should know which DLL to call to test that one in question? For a given <BR>> test code how I know what code it is actually being tested? And for the <BR>> code, how I know if there are test cases for it already or not? Even <BR>> though there is not much being tested in OS now, it is already confusing <BR>> to know of what exactly is being tested, where the tests are, and which <BR>> DLLs those tests are going to be compiled into.<BR>> <BR>> The two objectives above are not exclusive - they can be achieved <BR>> together. This is exactly what compile-time flags are for. This is why <BR>> GCC has a -d flag, etc. The build process should produce clean <BR>> execulables and DLLs for production releases, and debug executables and <BR>> DLLs for everything else.<BR>> <BR>> I would rather see test code being together with the code that is being <BR>> tested, and I would rather see test binary code going into the DLL that <BR>> is being tested too. There are some cases where a single test case spans <BR>> multiple codebases, but these are usually exceptions, and could go to a <BR>> single project-wide DLL with all the awkward tests - a DLL that is well <BR>> known to everyone.<BR>> <BR>> Otherwise, too much freedom will create more problems than necessary. <BR>> Simple question like: "where is the test code for this particular code <BR>> I'm looking at right now, and how I can run it" will become non-trivial.<BR>> <BR>> <BR>> -- <BR>> cheers<BR>> Mariusz<BR>> <BR>> _______________________________________________<BR>> Opensim-dev mailing list<BR>> Opensim-dev@lists.berlios.de<BR>> https://lists.berlios.de/mailman/listinfo/opensim-dev<BR><BR></body>
</html>