Test Organization | Test-Driven Development in Microsoft .NET (Microsoft Professional)

Now that we have tests for the data access layer, we can now look at the way our tests are organized. We have three categories in the test code: Entities, which test the entities in the database; Relationships, which test the relationships between entities; and Utilities, which test the supporting classes. The following is a detailed list of the fixtures in each category.

Entities
- ArtistFixture
- LabelFixture
- ReviewerFixture
- GenreFixture
- ReviewFixture
- TrackFixture
- RecordingGatewayFixture
Relationships
- TrackGenreFixture
- TrackRecordingFixture
- TrackArtistFixture
- ReviewReviewerFixture
- ReviewRecordingFixture
- RecordingArtistFixture
- RecordingLabelFixture
- RecordingReviewsFixture
Utilities
- IdGeneratorFixture
- SqlConnectionFixture

The first step of organizing the tests is to separate the tests into a different assembly. This separation is done so it s easy to make the decision about whether to ship the tests or not when the software is deployed. The downside of this is that the tests must access only public classes and public methods . Given the way that we wrote the tests, this is not a problem with the code we have because the tests only access the public interfaces of the classes in the data access layer. However, there are times when you want to access internal members . In these cases, you can either leave your tests in the assembly or create what is called a multi-module assembly, with the tests in one module and the code in another. The reason this is not done more often is that the current version of Visual Studio.NET (VS.NET 2002 and 2003) does not support the creation of multi-module assemblies in C# or VB.NET, so you have to use command-line tools to build them.

After the test fixtures have been moved to a different assembly, you can also put them in namespaces associated with the categories they test: Entities, Relationships, and Utilities. This obviously is optional, but it serves a purpose to indicate to future readers what the intent was when the code was written, and it makes it easier inside NUnit to see which category is having trouble.