Solution Folders in Enterprise Library
Solution Folders are a small but very useful new feature in Visual Studio 2005. If you haven't stumbled across them, they let you group the projects in your solution into a logical hierarchy, rather than have them all at the same level. They are particularly useful for solutions with a lot of projects - and Enterprise Library does have quite a few projects.
We've been trying out a couple of alternatives on how to use solution folders. Here are the options we're considering:
The two options are pretty similar, with the difference being on how the unit tests are organized (note that unlike EntLib 1.x, all unit tests are now in their own projects rather than in namespaces under the existing projects).
Option A has all of the unit tests grouped together under their own root solution folder. This means you can easily close this folder up if you don't want to see the unit tests. It also means that the unit tests are not really grouped anywhere near the code that they demonstrate - so it may make it harder to switch between the two.
Option B groups the unit tests together with the main projects. So they are harder to ignore (which may be a good thing or a bad thing, depending on your perspective), but they are always close to the code that they are testing.
Which would you prefer? Or if you have any other suggestions, that's fine too!
Comments
- Anonymous
October 28, 2005
I'm in favor of option B (unit tests grouped with main projects). Option A is like saying "Look this is my family all right here -- except for my mother-in-law whom we locked in the closet." - Anonymous
October 28, 2005
Please keep the unit tests with each individual block. Tests should be close to the code that is tested. Why? Because there is no excuse for a developer to OPEN the code if he is not going to CHANGE the code. And if a developer changes the code, he or she should add unit tests to test those changes. They should not have to dig unit tests out of some distant location. - Anonymous
October 28, 2005
Option B :) - Anonymous
October 28, 2005
Option B, of course.
But another question : in VS 2003 you have a special Project - that was similar with the project group in VB6 - that can contain one or more project.
I do not discovered this in VS2005 beta. is that feature replaced with "folders" ? - Anonymous
October 28, 2005
Im also in favor of option B and I totally agree with NickMalik. Tests should be close to the code being tested. To achieve that, there is also another possibility though. We did this also in VS2003: No special folder, but just use the name of the project that is being tested postfixed with '.UnitTest'. That way, the test is as close as possible to the code, without being in the same project. Then we use a further one-to-one mapping to have a test class for each class that is being tested - Anonymous
October 29, 2005
I like Option B. Even if I am not using Unit tests I can minimize the folder. But logically I still want it a subfolder of the unit tests.
Does arranging the unit tests this way make any difference to running tests inside visual studio? Can you run all these tests inside seperate projects? Or does option A easier to run all unit tests? - Anonymous
October 31, 2005
Option B. It's way cleaner than option A. - Anonymous
October 31, 2005
At first blush I thought Option A but the more I thought about it I realized that Option B is the best. Option B. - Anonymous
November 01, 2005
I'm not a risk taker. ;-)
Going with B. - Anonymous
November 01, 2005
Thanks everyone! B it is :-) - Anonymous
November 07, 2005
Excellent resolution. B is the best option IMHO. I can't wait to see the 2.0 blocks, the last Library had some of the most beautiful code and architecture I've had the privelege of working with. - Anonymous
November 07, 2005
Option B, Especially if you can set up some post build events to trigger the tests. Then you can right-click and build the folder for each block and the unit tests will be run auto-magically.