Databases Reference
In-Depth Information
the pure unit testing approach quickly grows out of control, often exceeding the size of
the business logic itself by a factor of five or more. Many development teams try and
quickly abandon the idea of automated testing because they cannot justify the effort
required to implement and maintain the unit tests that, due to their narrow focus, do not
significantly reduce the effort required perform the traditional system testing manually.
By starting with integration tests that exercise both business and data access logic, you
immediately begin receiving benefits of automated testing with a minimal investment of
effort. You know when your business logic fails either due to algorithmic errors or due to
configuration errors in the O/R mapping. As long as you create data required for your tests
programmatically, just as you would do in a unit test, the
TransactionScope
solves the
problem of keeping the database, a shared test environment, clean and ready for repeated
and reliable test execution. If developers on your team have local database environments,
you will be able run hundreds of integration tests per minute.
With the integration-first approach, you still have the option of introducing unit testing
for business logic
when
or
if
you discover that the number of tests has grown to the point
where running the entire suite takes too long. By then, the sheer number of the integra-
tion tests will serve as proof of success of automated testing on this project. You will also
have a good understanding of which integration tests are critical enough to be refactored
into unit tests to be executed by every developer locally and which can be left as-is for
your automated build to run on the server.
The
System.ComponentModel.DataAnnotations
namespace offers a number of validation
attributes discussed in this section. By placing validation attributes on the individual prop-
erties of entity classes, you can implement business logic declaratively. Aside from being
one of the quickest methods, declarative implementation of the business logic keeps it at
the highest level of abstraction—as close to the conceptual level in the Entity Data Model
designer as possible, helping the entity classes to stay easy to understand and maintain.
RequiredAttribute
The
RequiredAttribute
ensures that a value is not
null
and if the value is of type
string
,
it ensures that it is not empty as well:
[Required]
public object ProductName { get; set; }
Using the property definition just given, you can create the following test to verify that a
ValidationException
will be thrown by the
SaveChanges
method if a valid
ProductName
has not been specified for a new
Product
instance:
[TestMethod]
[ExpectedValidationException(MemberName =
“ProductName”
)]
public void ProductName_IsRequired()
