Building Enterprise Applications with Windows® Presentation Foundation and the Model View ViewModel Pattern by Raffaele Garofalo

Author:Raffaele Garofalo [Raffaele Garofalo]
Language: eng
Format: epub
Tags: COMPUTERS / User Interfaces
ISBN: 9780735661844
Publisher: Microsoft Press
Published: 2011-03-20T16:00:00+00:00

Test-Driven Development: The Data Layer

In Chapter 2, I stressed how important Test-Driven Development (TDD) is and why you need to introduce it at the beginning of the development process. Of course, the Data Layer also needs to be tested.

To test the Data Layer, you should follow two different directions, depending on the composition of the DAL. The first step is to test the mapping against the O/RM; you need to be sure that the entity is mapped properly in the O/RM, and that each field is mapped to the appropriate field in the database. For example, you don’t want the FirstName property of the Customer entity mapped to the LastName field of the Customer’s table.

To test the mapping, depending on the O/RM you are using, you should follow a few simple steps. First, you want to ensure that when you create and save a new entity, for example, a Customer entity, that the values are persisted properly in the database. To accomplish this test, you simply need to create a new entity, save it, retrieve it, and then check it against a static value.

public void CanSaveFirstName() { var firstName = "John"; var customer = Factory.Create<Customer>(); customer.FirstName = firstName; GenericRepository<Customer>.Add(customer); var expected = GenericRepository<Customer>.Get(customer.PrimaryKey); Assert.AreEquals(expected.FirstName, firstName); }

Such operations can be time-consuming, but are necessary when you need to be 100% sure that the mapping has been done properly and that no property is missing. If you are using Entity Framework, you might not need to execute this set of steps, because the UI designer makes it easy to see when the mapping has been done properly, especially if you generate your domain starting from an existing database.

If you’re planning to build a domain-first application, and you’re writing the mapping for your POCO objects manually, you must guarantee the mapping validity by using the TDD approach, which can be very expensive in terms of time and resources.

You should also remember that the data store used for the TDD should not be the same one you use for the final application, or you will end up with a set of “fake” records in the production data store.

The second type of tests should be executed only when you are not auto-mapping your model and if you are specifying different names for the data store fields than the names used for the entity fields. In my company, for example, we work with very private information, so we can’t use actual names in the database fields, because that would be a potential security breach. To accomplish this, we write tables and fields using numeric mappings, as shown in the following table:

Table

Field

Description

Download

Copyright Disclaimer:
This site does not store any files on its server. We only index and link to content provided by other sites. Please contact the content providers to delete copyright contents if any and email us, we'll remove relevant links or contents immediately.