[ moved from UnitTestsDefined ]

A USENET discussion of a good folder structure:

http://www.deja.com/threadmsg_ct.xp?AN=649350737

''So now, the question is how do structure the folder structure of the tests. I don'twant to interminge code and tests because that distracts me from my code. I also don't want to hide my tests because that slows down the process.''

Use the following structure. --Pierre G. Boutquin

	Common
		|
		------ Bin
		|
		------ Source
		|
		------ Data
		|
		------ Tests
		|
		------ Doc
	Project1
		|
		------ Common
			  |
			  ------ Bin
			  |
			  ------ Source
			  |
			  ------ Data
			  |
			  ------ Tests
			  |
			  ------ Doc
		|
		------ App1
			  |
			  ------ Bin
			  |
			  ------ Source
			  |
			  ------ Data
			  |
			  ------ Tests
			  |
			  ------ Doc
		|
		------ App2
			  |
			  ------ Bin
			  |
			  ------ Source
			  |
			  ------ Data
			  |
			  ------ Tests
			  |
			  ------ Doc
	Project2
	etc.
 
''What happens when App2 re-uses a file or object or package found in App1? I'd feel like adding a symbolic link somewhere.''
 
Common files go in the common directory. There is a common directory at the project level for files that get reused from project to project and a common directory under each project to store files that 2 (or more) apps in the same project share.

----

I see the point here. This is kind of like the structure we have here on a C++ project. Except every app has a structure too, not a plain collection of sources. I came from Smalltalk background and having to manage so many files hurts me... But worse, people here are not terribly oriented to reuse by themselves, and having complicated structure virtually prohibits most reuse attempts. The ability to make "links" in VCS helps somewhat, but this doesn't seem to be enough.
One of the things that makes me feel frustrated are discussions about where to put stuff, typically resolved within a day (!) with the project manager being involved. (Typical arguments include: "Because it's the way to do things".)
Sorry for the absence of concrete suggestions, but I've yet to find my own way of using C++ within the implied programming environment and culture.
-- PavelPerikov

----

We have been having trouble setting up unit testing under VisualBasic, or in particular under VisualSourceSafe because we found that VSS works much better if everything's in one folder.  And it seems that the key to testing is making it easy to run the tests.  If it's a pain to run the tests, you put off running them.  Some say this has already happened.

Running under VisualBasic and VisualSourceSafe there are a few possibilities:

	* Putting the VbUnit test project and the working project in different folders, and sharing the files.  You can either keep both projects open or switch between them, neither of which is that great.  This requires you to check in any files you want to test, which is dangerous because many of our modules are shared with other projects, and ideally you want to be sure they work first.
	* Putting both projects in the same folder, and sharing the actual physical copies of the files.  This makes it easy to do testing without checking your files in.  Then you can either
		* Keep both projects open at once.  This is really bad because VB may refuse to see changes in one project that you made in the other project.  It assumes that files don't change after you load them into the IDE.
		* Use a project group.  This works not too bad, but project groups have issues in VB in general, I've found, and especially regarding VisualSourceSafe.
		* Switch between projects.  This is what I usually end up doing.  In fact, if I can get away with it, I stay in the VbUnit test environment and write the code there to satisfy the tests.  This doesn't work very well for testing the interface, of course, but that's not what UnitTest''''''s are for, is it?

-- AaronHumphrey
----
CategoryTesting