MSDN Magazine - December 2008 - (Page 40)

up the database for those test inputs on each test run, but there’s an easier way. Let’s just use a fake database that can be more easily controlled in testing scenarios by using the Repository pattern to mediate between the application’s domain model and the data access services. Figure 3 Fake Database from IRepository public class InMemoryRepository : IRepository { private readonly Cache _types; private MockUnitOfWork _lastUnitOfWork; public InMemoryRepository() { _types = new Cache (type => { Type listType = typeof(List ).MakeGenericType(type); return Activator.CreateInstance(listType); }); } private IList listFor () { return (IList )_types.Get(typeof(T)); } public T Find (long id) where T : Entity { return listFor ().FirstOrDefault(t => t.Id == id); } public void Delete (T target) { listFor ().Remove(target); } public T[] Query (Expression<Func > where) { var query = from item in listFor () select item; return query.Where(where.Compile()).ToArray(); } public void Save (T target) { listFor ().Add(target); } My team has consistently chosen to use a Repository pattern with an IRepository interface: public interface Irepository { T Find (long id) where T : Entity; void Delete (T target); T[] Query (Expression<System.Func > where); void Save (T target); } } Figure 4 Test that Simulates a Database State [Test] public void find_the_user_by_user_name_and_password() { // Set up an InMemoryRepository with a User InMemoryRepository repository = new InMemoryRepository(); User user = new User(){UserId = "jeremy"}; user.ResetPassword("thePassword"); // the password is hashed repository.Save(user); // Construct a new instance of SecurityDataService using the // InMemoryRepository from above SecurityDataService service = new SecurityDataService(repository); service.Authenticate("jeremy", "wrong").ShouldBeFalse(); service.Authenticate("jeremy", "thePassword").ShouldBeTrue(); service.Authenticate("wrong", "thePassword").ShouldBeFalse(); service.Authenticate("wrong", "and wrong").ShouldBeFalse(); The real implementation of Repository uses NHibernate and LINQ for NHibernate to transfer information between the Entity objects and the database tables. In unit testing scenarios, all you really care about is that an Entity was saved, deleted, or available from this IRepository interface because that’s all that the rest of the application knows about. For testing, you can create a known database state by using an implementation of IRepository (see Figure 3) that simply stores objects in memory and uses LINQ-to-Objects instead of LINQ for NHibernate for querying. In unit tests, you construct objects that depend on IRepository with an instance of the InMemoryRepository that was set up with the desired data. Figure 4 shows a sample unit test that uses InMemoryRepository to simulate a database state. The sample tests the functionality of the SecurityDataService class (see Figure 5). Internally, it needs to query an IRepository for the existence of a user with a username and password. In the real application, the SecurityDataService uses the NHibernate Repository object that accesses the database. But in testing you can happily substitute a fake Repository that can easily be controlled to more quickly simulate multiple test cases. You can only do this type of substitution with fake objects if the classes that use IRepository only depend on the declared interface of IRepository. If the classes that use IRepository depend even indirectly on the fact that the normal IRepository does NHibernate-specific things, you won’t be able to cleanly substitute the fake object. Fake objects, such as stubs or mocks, are a huge advantage for doing emergent or continuous design by allowing you to build, and even design, a system incrementally by standing in for services that you haven’t yet created. Almost every project I work on contains at least one feature that requires the application to send automated e-mail notifications to the user depending on some sort of action and state in the system. But I most definitely do not want my application code getting hung up with e-mail functionality. I like to wrap up e-mail functionality by using the Gateway pattern. In the Gateway pattern, an object encapsulates access to an external system or resource. I want to pull every single piece of code it takes to send e-mails, including SMTP-type configuration, and hide it away from the rest of my code inside an IEmailGateway object, like this: public class EmailMessage { public string Body { get; set; } public string[] To { get; set; } } public interface IEmailGateway { void SendChangeStatusEmailTo(WorkflowState workflow, User owner); } The Gateway Pattern } Figure 5 Class to Be Tested public class SecurityDataService : ISecurityDataService { private readonly IRepository _repository; // The IRepository dependency is set up via Constructor Injection // In our real application, Both the real NHibernateRepository // and the SecurityDataService would be constructed by // an Inversion of Control container public SecurityDataService(IRepository repository) { _repository = repository; } public bool Authenticate(string username, string password) { return _repository.FindBy (u => u.UserId == username && u.Password == User.HashPassword(password)) != null; } } 40 msdn magazine Patterns in Practice

Table of Contents Feed for the Digital Edition of MSDN Magazine - December 2008

MSDN Magazine - December 2008 Contents Toolbox CLR Inside Out Advanced Basics Cutting Edge Patterns In Practice Team System Real-World WF Visual Studio OBA Tools SOA Data Access Geneva Framework Test Run Foundations Windows With C++ Going Places End Bracket

MSDN Magazine - December 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.