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:

Solution Folders options

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 (12)
  1. Mike Bouck says:

    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."

  2. Nick Malik says:

    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.

  3. Andrei Ignat says:

    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" ?

  4. 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

  5. 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?

  6. W.Meints says:

    Option B. It’s way cleaner than option A.

  7. Chris Kinsman says:

    At first blush I thought Option A but the more I thought about it I realized that Option B is the best. Option B.

  8. Steven Arteau says:

    I’m not a risk taker. 😉

    Going with B.

  9. Thanks everyone! B it is 🙂

  10. Thomas Kurek says:

    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.

  11. ryan says:

    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.

Comments are closed.

Skip to main content