Databases Reference
In-Depth Information
automated testing is difficult to apply
cost-effectively
. Many teams and individual develop-
ers have tried automated testing only to find that the significant increase in effort
required to implement and maintain the tests does not justify the perceived quality
improvements. In many instances, these attempts fail because developers try to apply the
“best practices” intended to tackle algorithmic complexity of some of the largest software
applications and frameworks. These practices do not scale down to the needs of the major-
ity of the information systems where the biggest challenge is the size of the domain (the
number of tables in the database, the number of human workflows, and so on) and not
the complexity of its individual algorithms.
Although the topic of automated testing is simply too big to cover in detail here, this
section presents a practical approach you can use to get started. To reinforce the impor-
tance of automated testing of business logic and to prove its practical value on application
development projects, the code examples in the remainder of this chapter demonstrate
validation logic in the form of automated tests.
Creating a Unit Test
To start implementing automated tests on your project, you need to create a test project
first. In most circumstances, you want your automated tests to be in separate assemblies to
avoid having them deployed in production environment. This example uses the Visual
Studio unit-testing framework, available in all editions, except Express. Visual Studio
provides a special project template, which you can choose using the Add New Project
dialog shown in Figure 8.5. By convention, the test project has the same name as the
project it tests, followed by the
.Tests
suffix. In this case, the project under test is
DataModel
, which is where the NorthwindEntities context class is defined along with the
entity classes, so the test project is called DataModel.Tests.
FIGURE 8.5
Adding a new test project to the solution.
