VusCode - Coding dreams since 1998!

Prism (CAL) unit testing - How to test Prism (CAL) Event Aggregator using Rhino Mocks

malovicn — Fri, 17 Apr 2009 22:41:54 GMT

I spent some time recently working with Microsoft Composite Application Guidance (A.K.A. "Prism", “CAL”) and I think it is very good platform for building composite UI by either using WPF or Silverlight.

One of its greatest advantages is that it was done in open source manner which resulted with most of the community feedback being incorporated into lightweight, testing friendly framework. Reference implementation and samples are also good but showing only static stubs based testing which is ok but not as powerful as mocking with some mocking framework.

My mocking framework of choice is Rhino Mocks and I am going to make couple of simple blog posts showing how to test Prism code using the Rhino Mocks in couple of typical every day scenarios.

And that leads us to today’s blog post…

How to test Prism (CAL) EventAggregator based code using Rhino Mocks?

SUT I’ll be using today will be as simple as possible to deliver the message.

LoggingService is service which is responsible for handling the logging of system errors in a way that:

subscribes to system wide events which are requested to be logged without referencing the event sources
decides if event needs to be published (based on severity)
if it does, it formats the system event adding the time stamp etc
calls the publishing service which is handling the publishing of formatted event

Considering the fact that in my sample we would be having various publishing services in system publishing to different targets(eventlog, flat text file) the LoggingService gets dependency injected only a component implementing the IPublishingService.

Subscription to system wide events on a decoupled manner is possible through EventAggregator design pattern which implementation is in Prism provided through IEventAggregator service.

The LogErrorEvent is an event to which LoggerService would subscribe and which carries the event argument of EventData type containing the ErrorLevel and ErrorMessage data.

Show me the code

Enough of my blabbering (and my English), code will speak for itself much better :)

Sample used in today's blog post can be downloaded here.

LoggingService

using System;
using System.Text;
using Microsoft.Practices.Composite.Events;

namespace Example
{
    public class LoggingService
    {
        private readonly IEventAggregator eventAggregator;
        private readonly IPublishingService publishingService;

        public LoggingService(IEventAggregator eventAggregator, IPublishingService publishingService)
        {
            this.eventAggregator = eventAggregator;
            this.publishingService = publishingService;
            this.eventAggregator
                .GetEvent<LogErrorEvent>()
                .Subscribe(this.LogIt);
        }

        private void LogIt(EventData eventData)
        {
            if (eventData.ErrorLevel<=100)
                return;

            var stringBuilder = new StringBuilder();
            stringBuilder
                .AppendFormat("Date:{0}", DateTime.Now)
                .AppendLine()
                .Append(eventData.ErrorMessage)
                .AppendLine();
            this.publishingService.PublishError(stringBuilder.ToString());
        }
    }
}

Nothing fancy there:

constructor accepts two parameters which provide to LoggingService access to event aggregator and publishing service through inversion of controls.
in constructor injected event aggregator is used for subscribing of LogIt method to LogErrorEvent.
LogIt method is private (wouldn’t work in case of Silverlight – but that is sepa rate blog post) and does next things:
- makes sure that only events with level greater then 100 get published
- formats the given error message into appropriate format
- pass the formatted message to publishing service

IPublishingService, LogErrorEvent and EventData

namespace Example
{
    public interface IPublishingService
    {
        void PublishError(string errorMessage);
    }
}

using Microsoft.Practices.Composite.Presentation.Events;

namespace Example
{
    public class LogErrorEvent : CompositePresentationEvent
    {
        
    }
}

namespace Example
{
    public class EventData
    {
        public int ErrorLevel { get; set; }
        public string ErrorMessage { get; set; }
    }
}

No need to waste time commenting this…

Testing the code

I could have done test first etc, but I believe that it would obfuscate the point of this blog , which now once we see the code being tested is going to be just showing the tests

Test 1 – How to make sure that event is getting subscribed

        /// 
        /// Shows how to verify that event aggregator subscription occurred.
        ///
        [TestMethod()]
        public void Ctor_Default_WouldSubscribeToLogErrorEvent()
        {
            // arrange
            var publishingServiceStub = MockRepository.GenerateStub<IPublishingService>();
            var eventAggregatorMock = MockRepository.GenerateStub<IEventAggregator>();
            var logErrorEvent = MockRepository.GenerateMock<LogErrorEvent>();

            // event aggregator get event would return mocked log error event 
            eventAggregatorMock.Stub(p => p.GetEvent<LogErrorEvent>()).Return(logErrorEvent);
            
            // expect that LogErrorEvent would be subscribed in constructor
            logErrorEvent
                .Expect(p => p.Subscribe(null))
                .Return(null)
                .IgnoreArguments() // we don't care which exact method or action subscribed, just that there was some.
                .Repeat.Once();

            // act
            var loggingService = new LoggingService(eventAggregatorMock, publishingServiceStub);

            // assert
            logErrorEvent.VerifyAllExpectations();
        }

The test is using Rhino Mocks AAA syntax introduced in 3.5 version (if you don’t know it, read Rhino Mocks Documentation Wiki excellent documentation).

In Arange section test:

defines two stubs for the services being used (stubs because I don’t care to set any expectation related to them in this test)
defines the mock of the event which subscription I am about to check
stubs the event aggregator behavior so on GetEvent<LoggErrorEvent>() method call would return event mock I created.
defines expectation on that event mock that subscription would occur once (IgnoreArguments() is there because this test doesn’t care really which method exactly would subscribe to event. Test cares only that subscription had occurred)

In Act section test just constructs the service

In Assert section test triggers verifying of the event log expectations (which in this test were: someone subscribed to this event)

(Note that making test for verifying that the Publish have occurred during the test would be pretty much the same as this test with a change on mocked expectations only)

Test 2a – How to invoke event aggregator in Act test section

Sometimes there is a behavior we want to unit test which is occurring upon the event being published through IEventAggregator and because we can be using anonymous delegate, private method handling the event (case of this blog post) there is no easy way to invoke functionality which is wanted to be tested.

This test shows how to invoke event aggregator to publish the desired event which would trigger code being tested,

In case of this example we want to test that not severe errors (error level <= 100) are not getting published.

        /// 
        /// An example of how to trigger event aggregator in act section
        ///
        [TestMethod()]
        public void LogIt_ErrorLevel100_WouldNotBePublished()
        {
            // arrange
            var logErrorEvent = new LogErrorEvent();
            var publishingServiceMock = MockRepository.GenerateMock<IPublishingService>();
            var eventAggregatorStub = MockRepository.GenerateStub<IEventAggregator>();

            eventAggregatorStub.Stub(p => p.GetEvent<LogErrorEvent>()).Return(logErrorEvent);
            
            // expect that publishing service would never be called
            publishingServiceMock
                .Expect(p => p.PublishError(Arg<string>.Is.Anything))
                .Repeat.Never();
            
            // act
            var loggingService = new LoggingService(eventAggregatorStub, publishingServiceMock);
            
            // invoke the event aggregator
            logErrorEvent.Publish(new EventData()
            {
                ErrorLevel = 100,
                ErrorMessage = "Some error message"
            });

           // assert
            publishingServiceMock.VerifyAllExpectations();
        }

In this test, test is having in Arrange section:

An instance of the log error event (not the mock of that event like in the case of previous test example)
Mock of the publishing service (in previous test we had stub) because that is service we need to check it won’t be called.
Stub of the event aggregator with stubbed GetEvent<LogErrorEvent> method
An expectation that PublishError method of the publishing service would never be called (regardless of the parameter being sent to that method)

In Act section test is :

constructing the logging service injecting the event aggregator stub and mock of publishing service
invoking the Publish method on a log error event instance passing the test data (error level == 100 in this test)

In Assert section, we are just triggering checking of expectation defined on mock of the publishing service (no call made to publish error method)

Test 2b – How to invoke event aggregator in Act test section

Although from perspective of this blog post it doesn’t have a lot of value here’s the test testing that publishing service will be called in case event will be published with error level greater then 100. (The more Rhino Mocks examples we have on web, the better adopting rate will be :))

	/// 
        /// An example of how to trigger event aggregator in act section
        ///
        [TestMethod()]
        public void LogIt_ErrorLevelGreaterThen100_WouldBePublished()
        {
            // arrange
            var logErrorEvent = new LogErrorEvent();
            var publishingServiceMock = MockRepository.GenerateMock<IPublishingService>();
            var eventAggregatorStub = MockRepository.GenerateStub<IEventAggregator>();

            eventAggregatorStub.Stub(p => p.GetEvent<LogErrorEvent>()).Return(logErrorEvent);

            publishingServiceMock
                .Expect(p => p.PublishError(Arg<string>.Matches(param => param.Contains("Some error message"))))
                .Repeat.Once();

            // act
            var loggingService = new LoggingService(eventAggregatorStub, publishingServiceMock);
            logErrorEvent.Publish(new EventData()
            {
                ErrorLevel = 101,
                ErrorMessage = "Some error message"
            });
            // assert
            publishingServiceMock.VerifyAllExpectations();
        }

Almost the same sample like previous one just with two small differences:

In arrange section, expectation is that the PublishError method would be called once with a method parameter containing “Some error message” string (inline constrains)
In act section, event is published with error level >100 to trigger the positive case when publishing service is been triggered

Green is nice :)

Conclusion

Thanks to P&P team and community feedback, CAL\PRISM event aggregator is implemented in such a way that mocking it is very easy (if not trivial) and every framework enabling easy testing is a good framework for me :) Good work P&P!

Technorati Ознаке: Prism,CAL,Test Driven Development,Mocking,RhinoMocks,nmalovic

Microsoft Unity Auto Mocking Container?

malovicn — Sat, 04 Apr 2009 13:07:00 GMT

How to build Microsoft Unity Auto Mocking container in less then 20 minutes of work…

I have written before in detail about Auto Mocking Containers so I’ll skip here details on what is it etc and jump to the main point of this post: implementation of auto mocking container for Microsoft Unity.

Faced with PIA caused by constant explicit mocking of constructor dependencies (some of them not even used in my tests), I’ve tried to Google my way out by searching for Unity AMC on Codeplex, Google code etc. To my surprise that didn’t went well with best match being Roy Osherove Unity AMC container blog post which is just a nice fluent interface allowing explicit mock creation and injection on easier way. In other words, nothing automatic happening there at least not in a sense I needed it for my tests.

I started looking for the Object builder documentation and found some for version one scattered on couple of sites. The only thing I get from that documentation was that ObjectBuilder is one complex thing and “patching it” was far away from my end design goal: quick solution.

So, once I realized that I can not solve this on ninja way I tried “brute force” approach and in 20 minutes I had working Unity AMC.

The idea is simple:

create a class specializing the UnityContainer - “AutoMockingUnityContainer”
override UnityContainer “Get” methods
wrap in try catch block every “Resolve” call
if ResolutionFailedException would occur using reflection find greediest constructor (with the most parameters)
if no constructor info available, return a mock
try to resolve those parameters by using AMC resolve method
recourse until you won’t have complete set of arguments needed (real or mocked instances) for constructing the originally requested instance

Code explaining the above mentioned concepts is even simpler so let cut the chase and save you from pain caused by reading more text written with “my English” ..

“Show me the code”

Imagine we would have a console application which is giving the answer on the meaning of the life

using System;
using Microsoft.Practices.Unity;

namespace ConsoleApplication1
{
    class Program
    {
        static void Main(string[] args)
        {
            IUnityContainer container = new UnityContainer();
            var user = container.Resolve<User>();
            Console.WriteLine(user.WhatIsTheMeaningOfTheLife());
            Console.ReadKey();
        }
    }
}

(Code creates UnityContainer instance and the uses it to retrieve instance of user class which WhatIsTheMeaningOfTheLife method is then shown in console output.)

User class is implemented like this:

namespace ConsoleApplication1
{
    public class User
    {
        private readonly ICompanyManager companyManager;

        public User(ICompanyManager companyManager)
        {
            this.companyManager = companyManager;
        }

        public int WhatIsTheMeaningOfTheLife()
        {
            return 42;
        }
    }
}

(User class constructor accepts ICompanyManager parameter which BTW is totally not used in the method used in console application.)

Although totally irrelevant for this blog post, here’s ICompanyManger class code (just not to have any secrets :)):

namespace ConsoleApplication1
{
    public interface ICompanyManager
    {
        void NotImportantMethod();
    }
}

If I would run this code as it is I would be rewarded by the nice Unity ResolutionFailedException

Resolution of the dependency failed, type = "ConsoleApplication1.User", name = "". Exception message is: The current build operation (build key Build Key[ConsoleApplication1.User, null]) failed: The parameter companyManager could not be resolved when attempting to call constructor ConsoleApplication1.User(ConsoleApplication1.ICompanyManager companyManager). (Strategy type BuildPlanStrategy, index 3)

Reason is pretty obvious: Unity container didn’t have any mapping defined for ICompanyManager which is required in order for user class to be required.

AutoMockingUnityContainer

Is just a class looking like this

using System.Diagnostics;
using Microsoft.Practices.Unity;

namespace UnityAMC
{
    public class AutoMockingUnityContainer  : UnityContainer
    {
        private readonly MockingHelper mockingHelper;

        public AutoMockingUnityContainer()
        {
             mockingHelper = new MockingHelper(this);
        }
        
        public override object Resolve(System.Type t, string name)
        {
            try
            {
                return base.Resolve(t, name); 
            }
            catch (ResolutionFailedException)
            {
                Debug.WriteLine(string.Format("Conflict resolution of type:{0}", t));
                return mockingHelper.ConstructInstance(t);
            }
            
        }
    }
}

As you can see no magic there and it does exactly what everyone would expect:

Inherit the UnityContainer
Override the Resolve method
Adds to that override Try Catch block which in case of ResolutionFailedException exception calls the mockingHelper ConstructInstance method
Mocking helper instance is stored in a field and constructed with pointer to current unity container in AMCContainer constructor

MockingHelper class

Is just 90 line long class looking like this:

using System;
using System.Diagnostics;
using System.Reflection;
using Microsoft.Practices.Unity;
using Rhino.Mocks;

namespace UnityAMC
{
    public class MockingHelper
    {
        private readonly IUnityContainer unityContainer;
        readonly MockRepository mockRepository = new MockRepository();
        private const string DebugCategory = "UnityAMC.MockingHelper";

        public MockingHelper(IUnityContainer unityContainer)
        {
            this.unityContainer = unityContainer;
        }

        #region Helper methods
        /// 
        /// Construct the instance.
        /// 
        /// The type which is to be constructed.
        /// An instance of service type.
        public object ConstructInstance(Type serviceType)
        {
            ConstructorInfo constructorInfo;
            try
            {
                constructorInfo = GetGreediestConstructor(serviceType.GetConstructors());
            }
            catch (Exception)
            {
                try
                {
                    Debug.WriteLine(string.Format("Mock created - {0}", serviceType), DebugCategory);

                    // returning mock of service not added to container
                    return this.mockRepository.DynamicMock(serviceType, new object[0]);
                }
                catch (Exception ex2)
                {
                    return new AutoMockingContainerContainerResolutionException(string.Format("Auto mocking failed for type:{0}", serviceType), ex2);
                }
            }

            var constructorParameters = constructorInfo.GetParameters();
            var arguments = new object[constructorParameters.Length];

            var counter = 0;
            foreach (var parameterInfo in constructorParameters)
            {
                arguments[counter++] = this.unityContainer.Resolve(parameterInfo.ParameterType, string.Empty);
            }

            return constructorInfo.Invoke(arguments);
        }

        /// 
        /// Gets the greediest constructor.
        /// 
        /// The constructor infos.
        /// Greediest constructor.
        private static ConstructorInfo GetGreediestConstructor(ConstructorInfo[] constructorInfos)
        {
            if (constructorInfos.Length == 0)
            {
                throw new InvalidOperationException("No available constructors.");
            }

            if (constructorInfos.Length == 1)
            {
                return constructorInfos[0];
            }

            var result = constructorInfos[0];
            for (int i = 1; i < constructorInfos.Length; i++)
            {
                if (constructorInfos[i].GetParameters().Length > result.GetParameters().Length)
                {
                    result = constructorInfos[i];
                }
            }

            return result;
        }
        #endregion
    }
}

GetGreediestConstructor method purpose is to get from a given collection of type constructor info's the one which has the most arguments.

ConstructInstanceMethod does next things:

For a given type tries to get greediest constructor
- If no constructor available on a given type (ex. in case of interface) it returns dynamic mock.
code then iterates through the greediest constructor parameters and tries to resolve each one of them
if resolution of any of them fails the procedure goes again just this time ConstructInstanceMethod would go one level deeper in object graph.

And that’s about it…

If I would modify my console app code to use AutoMockingUnityContainer instead of UnityContainer, I would end with code looking like this

using System;
using Microsoft.Practices.Unity;
using UnityAMC;

namespace ConsoleApplication1
{
    class Program
    {
        static void Main(string[] args)
        {
            IUnityContainer container = new AutoMockingUnityContainer();
            var user = container.Resolve<User>();
            Console.WriteLine(user.WhatIsTheMeaningOfTheLife());
            Console.ReadKey();
        }
    }
}

Which would run just fine…

Conclusion

Although I found this way of doing Unity AMC pretty naive and dumb, it works perfectly in my test fixtures for couple of months already with 20 minutes spent on making it. If anyone do this on ninja way, I would be more then happy to start using that but in the meantime … :)

My little code example can be downloaded from here

Technorati Ознаке: Unity,Mocking,Rhino,AutoMockingContainer

Fluent NHibernate – Convention over configuration – AutoPersistenceModel auto map magic

malovicn — Sat, 03 Jan 2009 14:58:56 GMT

Story about how fluent nhibernate idea was born

Fluent NHibernate is an open source project (fluent NHibernate trunk) which implements fluent interface on top of the NHibernate ORM configuration capabilities which are based on xml configuration files (as most of the Java ports are) where every entity is defined in it’s own configuration file.

The main reason behind existence of the Fluent NHibernate project is that working with those configuration files is not something very productive and (in general) it is one of the major turning off points for developers trying to get NHibernate.

As I mentioned in my Using NHibernate without configuration files post, it is possible to replace the act of creation of configuration files with the c# code where instead of every configuration file defining entities we would have separate mapping class. That functionality per se is awesome improvement comparing to configuration files, but it is still cumbersome work requiring a lot of repetitive work.

Here are couple of illustration of what kind of repentance I have on my mind with previous sentence:

My tables are having the same name as my entities (just in plural form)
I could have 50 entity classes where every identity property would be called ID and in database I would always have primary key consisting of “table name + ID”
Data table foreign key can be always defined following the naming rule of “parent table name + ID”
Most of my text based columns have 255 length characters
etc

Those rules are changing but each one of us (personally or on organization level) has a certain style of doing this things, predefined code and database standards on organization level or just agreement on team level. Based on that fact of convention existence, The Don Ayende asked for some magic to be added to Fluent NHibernate. His point was that he would like to be able to describe easily what the conventions (similar to the one I’ve enlisted above) are used in ORM area of the project and then based on those conventions fluent NHibernate should generate all of the configuration files automatically. Once those default configuration files state would be achieved, the developer would then modify configuration mappings to cover only the cases being an exception from the conventions.

Brilliant minds behind Fluent NHibernate get their heads together and implemented that AutoMap functionality Ayende was asking and I was recently playing with it and want to share my experiences with the community.

(Source code of the example used in this blog post can be found here)

Blog post set up

I’ll use the same example as the one I’ve used in Using NHibernate without configuration files post. The good side of that decision is that you would be able to see same example done on both (manual and auto map) ways but on the flip side (to understand in detail what is the use case scenario etc) you would have to read the original post because here I would just summarize it.

Class diagram

SQL Database model

Couple of major points to be noted here:

Customer has an address (Customer.CustomerAddress property) and a collection of reference people handling his requests (References property)
SQL Data model has two tables while class diagram has 3 classes. The difference is that Address class data on database level is embedded into customer table. In NHibernate parlance, that is called component.
Class diagrams all have their identity property named “ID” while database primary key columns are named following the “table name + ID” rule.
Database table names are plural form of class entities. (Customer –> Customers, ReferencePerson –> ReferencePeople)
ReferencePerson class has property named LastName while ReferencePeople table has column named SurName
All of the entities implement IEntity which is totally not necessary for this example and\or your code but is something so commonly used that most of the examples on the web contain base entity class or interface. That’s why I added IEntity to this example to illustrate how AutoMap works in that use case too

Project structure

The project structure of the solution used in this example looks like this:

BusinessLayer project contains entities presented in calss diagram without referencing infrastructure (PI\POCO design criteria)
NHibernateInfrastructure project contains two files:
- Inflector – this class is “borrowed” from Active Record code base and it sole purpose is to pluralize entity names to database table names
- NHibernateBootstrapper.cs is a class which performs complete initialization of NHibernate engine based on auto map and manual definitions and result with NHibernate session being created at the end of build up process. Most of this blog post would be related to this class
NHibernateInfrastructure.Test project contains test fixture (MappingTest) similar to the one from the manual map post.

An example of Fluent NHibernate auto mapping functionality

Before I start

Unfortunately there are no official documents presenting “the right way” to do this auto mapping. Most of the examples on net are covering same trivial example and they are not very helpful too. (Btw, lack of documentation was the reason behind writing this blog post) .I am by no mean expert in fluent NHibernate so while the code presented in this blog post is fully functional there might be some better ways how to do some of the presented functionality. In other words, take the example code bellow more as a starting point and spend some time with Fluent NHibernate examining it. It would be very worth spent time, I can promise you that.

Now the disclaimer is done, let’s roll :)

High level overview

Here’s the content of NHibernateBootstrapper.cs class (warning: significant amount of code coming but worth of reading I hope :) )

        
public ISessionFactory InitSessionFactory()
        {
            var config =
                    MsSqlConfiguration.MsSql2005
                    .ConnectionString.Is(
                        @"Data Source=.\SQL2008;Initial Catalog=NHibernateBlog;" 
                        + @"Integrated Security=True")
                    .UseReflectionOptimizer()
                    .ConfigureProperties(new Configuration());

            // 1. defining conventions and scope of the auto persistence model
            var autoPersistenceModel = GetPersistenceModelFromAutoMapping();
            
            // 2. defining exclusions form auto persistence 
            UpdatePersistenceModelWithExclusions(autoPersistenceModel);

            // 3. overriding auto mapping defaults
            UpdatePersistenceModelWithManualMappingInformations(autoPersistenceModel);

            // 4. writing auto mapping definitions (needed just for blog post) 
            autoPersistenceModel.WriteMappingsTo(@"C:\Temp");
            
            // 5. Configuring NHibernate configuration using auto persistence model
            autoPersistenceModel.Configure(config);

            // returning session factory from given configuration
            return config.BuildSessionFactory();
        }

InitSessionFactory is the the only public method which is called from application assembly and which task is to return session factory created based on defined mapping informations.

Beginning of the method is related to creating Sql 2005 standard configuration (NHibernateBlog DB backup file is given in zip file accompanying this blog post)

Then the method perform 5 step configuration initialization:

Create AutoPersistanceModel containing all the default mapping rules regarding how and what to auto map.
Define domain elements which are to be excluded from the auto mapping persistence model definition due to the fact that they don’t fit to defined conventions
Define all of the manual mapping information fore domain elements which are not auto mapped
Write mappings xml configuration files to hard drive (not needed in production, just for you to check out the result of the fluent NHibernate auto mapping routine)
Configure NHibernate configuration with AutoPeristenceModel initialized in steps #1 - #3

Once NHibernate is configured session factory is built and returned for further consumption.

Now when we saw high level steps, let check out how those steps look in more detail..

Creating of AutoPersistenceModel

Let see what is inside of the GetPerisicatnceModelFromAutoMapping method

namespace NHConfigMappings
{
   ...
       private static AutoPersistenceModel GetPersistenceModelFromAutoMapping()
        {
            return AutoPersistenceModel.MapEntitiesFromAssemblyOf<Customer>()
                    
                    // defining what is to be auto mapped
                    .Where(type =>
                                    typeof(IEntity).IsAssignableFrom(type) 
                                    && type.IsClass 
                                    && !type.IsAbstract
                                    && type.Namespace == "CustomerConfiguration")
                    
                    // defining convention attributes
                    .WithConvention(convention =>
                    {
                        convention.FindIdentity = p => p.Name == "ID";
                        convention.GetTableName = type => Inflector.Pluralize(type.Name);
                        convention.GetPrimaryKeyNameFromType = type => type.Name + "ID";
                        convention.GetForeignKeyNameOfParent = p => p.Name + "ID";
                        convention.DefaultStringLength = 50;
                        convention.OneToManyConvention = o => o.Cascade.All();
                    });
        }
   ...	
}

AutoPersistenceMode has a static factory method MapEntitiesFromAssemblyOf<T> where T is a type defined in a assembly containing entities which are about to be auto mapped. Very cool way for providing assembly name information. In the case of this blog post, Customer type is defined in BusinessLayer asembly, so this line would provide that information to fluent nhibernate auto mapping logic.

Then there’s a Where method which purpose is to define what types of a given assembly are to be mapped. In a sense it defines filter constraint criteria for auto mapping logic. In the case of this blog post, filter criteria is set to something like “all non abstract types implementing the IEntity which are defined in CustomerConfiguration namespace” . Any type not matching those rules wouldn’t be included in auto mapping process.

Once I’ve defined “what”, I start defining “how” by defining auto mapping conventions which are set of general settings defining how auto mapping logic should behave.

In the case of this blog post, conventions are defined like this:

Every class would have identity property with name “ID” (If your property would be named “Id” there won’t be need for explicit definition because that is default setting Fluent Nhibernate uses)
Database table name should be plural form of the class entity name (example: class Customer –> table Customers)
Primary key column name would consist of type name and “ID” suffix (example: PK of Customer table would be named CustomerID)
Foreign key column name would consist of parent type name and ID suffix (example: FK of ReferencePeople table would be CustomerID)
Every string class property would be by default mapped to 50 character length column
Every One – To – Many mapping would have Cascade.All cascade setting by default

Defining exclusions from AutoPersistenceModel definition

Now when I defined default mapping rules, I need to define what needs to be excluded from that auto mapping

namespace NHConfigMappings
{
        private static void UpdatePersistenceModelWithExclusions(AutoPersistenceModel persistenceModel)
        {
            persistenceModel
                    .ForTypesThatDeriveFrom<Customer>(c => c.IgnoreProperty(p => p.CustomerAddress))
                    .ForTypesThatDeriveFrom<ReferencePerson>(c => c.IgnoreProperty(p => p.LastName));
        }
   ...	
}

As we can see here I’ve defined next exclusions:

Cutomer.CustomerAddress property shouldn’t be auto mapped (because that would be Component and not One-To-Many type of mapping)
ReferencePerson.LastName property shouldn’t be auto mapped (LastName property wouldn’t be mapped to LastName column)

Adding manual mapping definition to AutoPersistenceModel

For all of the non mapped and excluded exceptional entities which we still need to map to database entities, Fluent Nhibernate defines a way of adding manual mapping definitions to auto map defined auto persistence model

Here’s the code sample:

namespace NHConfigMappings
{
   ...
        private static void UpdatePersistenceModelWithManualMappingInformations(AutoPersistenceModel persistenceModel)
        {
            // adding manual mapping to auto mapped persistence model 
            // 1. column level exceptions
            persistenceModel.FindMapping<ReferencePerson>().Map(p => p.LastName, "SurName");

            // 2. components definition
            persistenceModel.FindMapping<Customer>()
		.Component<Address>            (
                    x => x.CustomerAddress,
                    m =>
                    {
                        m.Map(x => x.Street).WithLengthOf(100);
                        m.Map(x => x.PostalCode).WithLengthOf(6);
                        m.Map(x => x.Town).WithLengthOf(30);
                        m.Map(x => x.Country).WithLengthOf(50);
                    });
        }
   ...	
}

UpdatePersistenceModelWithManualMappingInformations method updates persistance model like this:

In auto persistence model definition find mapping for ReferencePerson entity and add mapping of the LastName property (to be mapped to SurName property)
In auto persistence model definition find mapping for Customer entity and add component mapping for CustomerAddress property as defined in code sample

Checking the xml configuration files

Let’s take a quick peek at how configuration files generated from AutoPersistenceModel would look like

CustomerConfiguration.Customer.xml

<?xml version="1.0" encoding="utf-8"?>
<hibernate-mapping xmlns="urn:nhibernate-mapping-2.2" default-lazy="true" assembly="CustomerConfiguration" namespace="CustomerConfiguration">
  <class name="ReferencePerson" table="ReferencePeople" xmlns="urn:nhibernate-mapping-2.2">
    <id name="ID" column="ReferencePersonID" type="Guid">
      <generator class="guid.comb" />
    </id>
    <property name="LastName" column="Surname" length="50" type="String">
      <column name="Surname" />
    </property>
    <property name="FirstName" column="FirstName" length="50" type="String">
      <column name="FirstName" />
    </property>
  </class>
</hibernate-mapping>

CustomerConfiguration.ReferencePerson.xml

<?xml version="1.0" encoding="utf-8"?>
<hibernate-mapping namespace="CustomerConfiguration" assembly="CustomerConfiguration" default-lazy="true" xmlns="urn:nhibernate-mapping-2.2">
  <class name="ReferencePerson" xmlns="urn:nhibernate-mapping-2.2" table="ReferencePeople">
    <property name="LastName" type="String" length="50" column="Surname">
      <column name="Surname" />
    </property>
  </class>
</hibernate-mapping>

Now imagine you have hundreds of tables and entities and think about how much time and effort Fluent Nhibernate auto mapping functionality saves. Neat isn’t it?

Testing the AutoPersistenceModel based auto mappings

For the end of the blog post there’s only one thing left and that is to run the same test I wrote for Using NHibernate without configuration files post and to show that auto mapping works like it was working with manual class map definition

Here’s test fixture code…

namespace NHConfigMappings.Test
{
    using System.Collections.Generic;
    using CustomerConfiguration;
    using Microsoft.VisualStudio.TestTools.UnitTesting;
   using NHibernate;

    [TestClass]
    public class MappingsTest
    {
        private static ISessionFactory _sessionFactory;

        [ClassInitialize]
        public static void FixtureInit(TestContext testContext)
        {
            _sessionFactory = new NHibernateBootstrapper().InitSessionFactory();
        }

        [TestMethod]
        public void ReferencePerson_Create_ShouldCreateRowInDb()
        {
            var customer = new Customer
               {
                   Name = "John Doe",
                   CustomerNumber = "12345",
                   CustomerAddress = new Address
                                         {
                                             Street = "1st Mayson Street",
                                             PostalCode = "01754",
                                             Town = "Maynard",
                                             Country = "USA"
                                         },
                   References = new List
                                          {
                                              new ReferencePerson
                                                  {
                                                      FirstName = "Nikola",
                                                      LastName = "Malovic"
                                                  }
                                          }
               };

            ISession session = _sessionFactory.OpenSession();
            session.Save(customer);
            session.Flush();

            session.Evict(customer);
            
            var customerDB= session.Get<Customer>(customer.ID);
            Assert.IsTrue(  customerDB.ID == customer.ID && customerDB.Name == customer.Name 
                            && customerDB.CustomerAddress.Street == "1st Mayson Street"
                            && customerDB.References[0].FirstName == "Nikola");

        }
    }
}

The main difference between tests in previous blog post and this one is that we don’t have in fixture init explicit session factory initialization. Instead, there’s only call to NHIbernateBootstrapper class InitSessionFactory method which I’ve already presented in this blog post. Test method is completely the same as the one from previous post. So it is the result of test run

Conclusions

NHIbernate rock!
Fluent NHibernate Auto mapping functionality rock!

There are a lot of blog posts about auto mapping functionality you might want to check out:

Technorati Oznake: NHibernate,Fluent NHibernate,ORM,nmalovic

Dependency injection in real world

malovicn — Tue, 23 Dec 2008 10:45:13 GMT

Patrick left a comment on one of my previous blog posts asking a couple of very interesting questions that I’ve been asking myself too:

Is service locator legitimate way of doing IoC?

(I’ll use example code from that blog post as a base for my today blog post so in case you are idle enough you can go and check it out)

Dependency injection primer

Let me start with an example how “real” dependency injection implementation code from my blog post could look like:

using System;
using System.Collections.Generic;

namespace Example.UserManager
{
    public class UserManagerIoC
    {
        private readonly IUserProvider userProvider;

        public UserManagerIoC(IUserProvider userProvider)
        {
            this.userProvider = userProvider;
        }

        public int NumberOfUsersActiveInLast10Days(string userName)
        {
            var userCollection = this.userProvider.GetUserCollection();
            int result = 0;
            foreach (User user in userCollection)
            {
                if (user.Name.StartsWith(userName) && user.LastActivity > DateTime.Now.AddDays(-10))
                    result++;
            }
            return result;
        }
    }
}

As we can see from the simple code above, code has one constructor which accepts the IUserProvider parameter and then stores its pointer to a field so it can be used later in a method which performs some kind of business logic.

Key concept here to be noticed is that class have literally no clue where from and how userProvider would get injected.

How DI based unit test looks like?

I’ll use Microsoft Unity and Rhino mocks to write a test for the dependency injection primer.

Here it is:

using System.Collections.Generic;
using Example.UserManager;
using Microsoft.Practices.Unity;
using NUnit.Framework;
using Rhino.Mocks;

namespace UserManager.Test.IoC
{
    [TestFixture]
    public class UserManagerTestIoC
    {
        private MockRepository mockRepository;
        private IUnityContainer unityContainer;

        [SetUp]
        public void Test_Init()        
        {
            this.mockRepository = new MockRepository();
            this.unityContainer = new UnityContainer();
        }

        [Test]
        public void GetActiveUsers_TestCaseOfZeroUsers_WouldReturnEmptyCollection()
        {
            var userProvider = this.mockRepository.DynamicMock<IUserProvider>();
            // injecting to unity container mocked instance of user provider
            this.unityContainer.RegisterInstance(userProvider);
            
            using (this.mockRepository.Record())
            {
                Expect.Call(userProvider.GetUserCollection())
                    .Return(new List<User>());
            }
            using (this.mockRepository.Playback())
            {
                // using IoC container for UserManager construction 
                var userManager = this.unityContainer.Resolve<UserManagerIoC>();
                
                // and then performing tested code 
                int numberOfUsers= userManager.NumberOfUsersActiveInLast10Days("X");
                Assert.IsTrue(numberOfUsers == 0);
            }
        }  
    }
}

What I did in that test:

I am instantiating UnityContainer in test set up to be used as IoC container.
In first line of test method I am using Rhino mocks to create mock of IUserProvider and then I inject that mock to Unity IoC container
In a first line of recording block, I set expectation that empty user collection would be returned
In playback block, I get an instance of UserManagerIoC class by using IoC container Resolve factory method. (KEY POINT)
IoC container would then:
- examine the constructor of UserManagerIoC class,
- see that IUserProvider parameter is requested
- try to find in IoC container registered service implementing IUserProvider interface
- mocked instance we injected at the beginning of the test would be found
- mocked instance would be injected to UserManagerIoC
Method would be executed and the expected number of users checked

NOTE #1: You could get away from explicit dependency mocking by using AutoMockingContainer but I decide to do it anyhow in this post in order to increase example readability.

NOTE #2: You could also opt to use var userManager = new UserManager(userProvider) but this is not something typically you would do because userProvider can have it’s own dependencies and so on… Not using IoC container in the test would mean not using one of its most important features: auto dependency resolution.

Dependency injection upsides and downsides

As we can see, we were able to keep UserManager light and ignorant about IoC infrastructure, while utilizing the benefits dependency injection provides us (increased testability in this example)

Still there are couple of problems (not sure if I can call them like this) related to this implementation which I’ve witnessed in last couple of months and which can be summarized as:

Brownfield scenarios
UserManager is already existing class built without having dependency injection on mind (no constructor exposing abstracted dependencies). While it is hard to sell the business value of refactoring UserManager internals to expose dependencies through constructor (sell tagline: to test it) it is mission impossible getting approval for updating all of the million places currently doing the UserManager um = new UserManager() to become unityContainer.Resolve<UserManager>() (Sith language : “What’s the business value?”) and without that change no DI going to happen.
Code monkey scenarios
Vast majority of developers I know don’t get the IoC, TDD etc, which means that one would spend ton of time answering the
“Why I can not just new the instance?”, “This is clearly an overkill…”, “Here it is him with his damn patterns making my life miserable”, “Why I need to decouple DB from my unit tests at all?”..
Although this reason might look “not-so-important”, if you are not lucky to work in TDD friendly environment, if you are working in company which DEV teams span across the globe this could be real show stopper.
“TDD == unit test”
If you are doing unit tests AFTER the code is been done then it is very hard to sell to PMs the need for “all that complexity”.
In other words, if they don’t get that in TDD the most important thing is not the “T” (test) but the “DD” (driven design) whole DI thing start to get harder to be sold
“Why IoC framework X?”
”Why UnityContainer?” “Why not Castle?” “Why not Spring?” “Why not StructureMap?” “On my previous job I worked with XYZ and it is the best…”

ServiceLocator based dependency injection

Luckily, I think I found a way how to go around the restrictions mentioned above with keeping the dependency injection in place and high testability. I’ve wrote in more details in my DFT blog post series so here I’ll just summarize it…

The key points that solution has to achieve are:

Core code implementation has to utilize dependency injection
Code has to be “open for testing” but “close for development” (yes, I am aware how stupid this might sound and it it stupid thing – details bellow )
DI enabling existing code is not allow to cause any breaking compatibility issues (KIC - “keep it cheap” design principle)
No dependency on any particular IoC framework

Lets take a look at the same primer I’ve done with DI this time implemented using service locator

using System;
using Facade;

namespace Example.UserManager
{
    public class UserManagerSL
    {
        private readonly IUserProvider userProvider;

        public UserManagerSL(): this (ServiceLocator.Retrieve<IUserProvider>())
        {
        }

        internal UserManagerSL(IUserProvider userProvider)
        {
            this.userProvider = userProvider;
        }

        public int NumberOfUsersActiveInLast10Days(string userName)
        {
            var userCollection = this.userProvider.GetUserCollection();
            int result = 0;
            foreach (User user in userCollection)
            {
                if (user.Name.StartsWith(userName) && user.LastActivity > DateTime.Now.AddDays(-10))
                    result++;
            }
            return result;
        }
    }
}

Main differences (compared to dependency injection primer) are:

We still have public parameter less constructor
That parameter less constructor uses ServiceLocator to retreive instace of IUserProvider on a same way UnityContainer retrieved it in previous test.
ServiceLocator is just a Facade wrapper around IoC container encapsulating the type of container and hiding not used features.
Achieved design goal: “Keep it cheap”
Achieved design goal: “No dependency on particular IoC framework”
In some bootstrapper class tied to app start event I will have to define ServiceLocator mapping for service implementing the IUserProvider so the code would work normally like it was working before the dependency injection
Constructor taking IUserProvider parameter is now internal.
The assembly containing UserManagerSL class would contain next attribute
```
[assembly: InternalsVisibleTo("UserManager.Test.SL")]
```

Result of this attribute would be that this constructor would be:

- visible to test assembly containing test methods using UserManagerSL
- not visible to any code outside of that test assembly (none of the “core DEV” would be aware of it)

Achieved design goal: “Open for test, close for development”
Achieved design goal: “Dependency injection used in code”

How ServiceLocator based test looks like?

Here are two examples how the service locator code can be tested..

“White box” service locator test style

using System.Collections.Generic;
using Example.UserManager;
using Facade;
using NUnit.Framework;
using Rhino.Mocks;

namespace UserManager.Test.SL
{
    [TestFixture]
    public class UserManagerTestSL
    {
        private MockRepository mockRepository;
        private IUserProvider userProvider;

        [SetUp]
        public void Test_Init()        
        {
            this.mockRepository=new MockRepository();

            // registering mock of IUserProvider with ServiceLocator
            this.userProvider = this.mockRepository.DynamicMock<IUserProvider>();
            ServiceLocator.InjectStub(this.userProvider);
        }

        [Test]
        public void GetActiveUsers_TestCaseOfZeroUsers_WouldReturnEmptyCollection_WithSL()
        {
            using (this.mockRepository.Record())
            {
                Expect.Call(this.userProvider.GetUserCollection())
                    .Return(new List<User>());
            }
            using (this.mockRepository.Playback())
            {
                // using internal constructor
                var userManager = new UserManagerSL();
                int numberOfUsers = userManager.NumberOfUsersActiveInLast10Days("X");
                Assert.IsTrue(numberOfUsers == 0);
            }
        }
    }
}

In this testing style we feed the service locator with the list of internal dependencies we know it is been used by the tested code and then in our test method we totally don’t care about dependency injection (constructors used are empty, no service locator usage anywhere outside of SetUp method)

I personally don’t like this style of testing (based on intimate knowledge of tested code) but I’ve seeing it working in the past.

Using internal constructor

Second approach is based on the fact that internal constructor is accessible to test assembly which makes test built on this way very simple

using System.Collections.Generic;
using Example.UserManager;
using NUnit.Framework;
using Rhino.Mocks;

namespace UserManager.Test.SL
{
    [TestFixture]
    public class UserManagerTestSL
    {
        private MockRepository mockRepository;

        [SetUp]
        public void Test_Init()        
        {
            this.mockRepository=new MockRepository();
        }

        [Test]
        public void GetActiveUsers_TestCaseOfZeroUsers_WouldReturnEmptyCollection()
        {
            IUserProvider userProvider = mockRepository.DynamicMock<IUserProvider>();

            using (mockRepository.Record())
            {
                Expect.Call(userProvider.GetUserCollection())
                    .Return(new List<User>());
            }
            using (mockRepository.Playback())
            {
                // using internal constructor
                var userManager = new UserManagerSL(userProvider);
                int numberOfUsers = userManager.NumberOfUsersActiveInLast10Days("X");
                Assert.IsTrue(numberOfUsers == 0);
            }
        }
    }
}

In this example we don’t use at all service locator. Instead we simply inject mocked instance of user provider to internal constructor. All of the downsides of this approach (mentioned in dependency injection note #2) are applicable here to.

Using dependency injection

The best thing with my service locator based design approach is that while some of the “not so TDD skilled” developers can do testing on the first two ways, “TDD skilled” developer can still write exactly the same test as the one given in the dependency injection section of this blog post.

Check it for yourself:

        [Test]
        public void GetActiveUsers_TestCaseOfZeroUsers_WouldReturnEmptyCollectio_IoC()
        {
            var userProvider = this.mockRepository.DynamicMock<IUserProvider>();
            // injecting to unity container mocked instance of user provider
            ServiceLocator.InjectStub(userProvider);

            using (this.mockRepository.Record())
            {
                Expect.Call(userProvider.GetUserCollection())
                    .Return(new List<User>());
            }
            using (this.mockRepository.Playback())
            {
                // using IoC container for UserManager construction 
                var userManager = ServiceLocator.Retrieve<UserManagerSL>();

                // and then performing tested code 
                int numberOfUsers = userManager.NumberOfUsersActiveInLast10Days("X");
                Assert.IsTrue(numberOfUsers == 0);
            }
        }

Summary

Most of the blog posts I’ve seen present an ideal “perfect day” situation setup for writing the test which is not always the case in real world.

In this kind of “not-so-perfect” situations, service locator based solution I’ve presented in that blog post allowed me to increase testability and introduce TDD into existing code bases and environments not so much interested in the TDD.

Source code for this blog post can be found here.

Technorati Tags: TDD,DFT,Service Locator,Dependency Injection,Unit testing,Rhino mocks,nmalovic

Fluent NHibernate – NHibernate without configuration files

malovicn — Sun, 31 Aug 2008 10:39:28 GMT

NHibernate is great, (no doubt about it) but every time I was supposed to work with it, the fact that I had to manually type in all those xml configuration entries was something I really didn’t like at all.

The most important complains I personally have on NHibernate configuration files are:

It is error prone
Errors in configuration file can be hard to trace
It is not refactoring friendly
It is not C#, it is XML :-)

I believe that the most important reason why NHibernate is not more widely adopted by general DEV population is exactly the “Java XML configuration” PIA feeling you have while working with it.

Great news for all of us from that group: NHibernate is possible to be used WITHOUT configuration files!

Who, what and where?

Jeremy Miller coded initial bits of the Fluent NHibernate project and then James Gregory with couple of guys more bring the project to Google code and they started finalizing it. OSS rules!

So, if you go to http://code.google.com/p/fluent-nhibernate/ you would see names of other project members together with the simple code illustrating the goal fluent nhibernate project tries to achieve.

As with the most OSS projects, to get the source code of FNH, download it from Subversion trunk located at http://fluent-nhibernate.googlecode.com/svn/trunk/

Solution file consist of couple of projects:

LIb solution folder contains DLL you would be using in your application.
Test project containing a bunch of unit tests which you can use as starting point to get detail understanding on how the things works.
Quick start project which highlights most important concepts you need to start using NHibernate

Note: Project is initially built with NHibernate 2.0 which collides with Linq For NHibernate (using NHibernate 2.1) so I updated FNH project references to use 2.1 too

Fluent NHibernate in action

Solution project structure

In this blog post, I will use the same example Jimmy Nilsson used in his Applying Domain-Driven Design and Patterns: With Examples in C# and .NET NHibernate chapter so you can compare outcome of my blog post sample it with how it looked in his book (with the configuration files in place).

Solution file of today’s example contains 3 projects:

BusinessLayer (“Domain”)
Contains definitions of entities which we use in modeling business use cases.
Important to be mentioned here is that BusinessLayer project doesn’t have any reference to neither other projects of this solution nor the “3pty dlls” such is NHibernate.dll
NHConfigMappings (“Mapping project”)
Contains ORM mapping definitions which enables nhibernate to persist to relational DB domain entities
NHCongigMappings.Test

Contains test fixture illustrating how mappings should be consumed and how nhibernate engine could be initialized without any xml configuration files

(Source code used in today blog post can be download from here)

Domain project

As you can see, it is very simple sample where we have entity customer class containing “embedded” Address value object and referencing the list of reference persons customer contacted.

Same diagram given in code would look like this

using System;
using System.Collections.Generic;

namespace CustomerConfiguration
{
    public class Customer
    {
        public virtual Guid Id { get; set; }

        public virtual string CustomerNumber { get; set; }

        public virtual string Name { get; set; }

        public virtual Address CustomerAddress { get; set; }

        public virtual IList ReferencePersons { get; set; }
    }
}

Address type will look like this:

namespace CustomerConfiguration
{
    public class Address
    {
        public virtual string Street { get; set; }
        public virtual string PostalCode { get; set; }
        public virtual string Town { get; set; }
        public virtual string Country { get; set; }
    }
}

And ReferencePerson type would look like this:

using System;

namespace CustomerConfiguration
{
    public class ReferencePerson
    {
        public virtual Guid Id { get; set; }

        public virtual string FirstName { get; set; }

        public virtual string SurName { get; set; }
    }
}

As you can see from the code above, NHibernate allows us fully persistent ignorant \POCO software development: no special attributes, no special base class or interface…

Mapping project

Once we have domain logic defined, we need to provide information on how NHibernate should map our classes with appropriate DB entities: tables and columns.

For my example DB would look like this:

As you can see, although in my code I have separate Address class I don’t have it in DB. Instead I have it embedded in Customer table as last 4 columns. Also, table names in DB are in plural form while names of classes are in singular form.

Another small difference here is that in ReferencePerson class has a LastName property while DB has column SurName.

Mapping ReferencePerson

I won’t throw in here example of how that would look if I would use XML configuration file, because the whole point is to forget that ASAP :) (In case you want to see it, check it out here)

In order to define NHibernate mapping, in FNH you need to create a mapping class for each one of entities (which is something Ayende don’t get).

That mapping class should inherit from ClassMap<T> class in order to get access to FHN members providing programmatic access over configuration settings

using CustomerConfiguration;
using FluentNHibernate.Mapping;

namespace NHConfigMappings
{
    public class ReferencePersonMap : ClassMap<ReferencePerson>
    {
        public ReferencePersonMap()
        {
            TableName = “ReferencePersons”;
            
            Id(x => x.Id).GeneratedBy.GuidComb()
                .WithUnsavedValue(“00000000-0000-0000-0000-000000000000”);

            Map(x => x.FirstName).WithLengthOf(50).CanNotBeNull();
            Map(x => x.LastName,”SurName”).WithLengthOf(50).CanNotBeNull();
        }
    }
}

Main advantage of fluent interface is that it produces code with good readability, which I believe we can see from code snippet above.

In a class constructor, I am defining:

What is the name of data table where the class will be persisted. In my example table name and class name differs so I had to define it here, but I think it is good practice to define it always, even they are implicitly the same by the default
Which class property should be used as Identity Field populating table PK. In example I took I am using ReferenceMap.Id property where NHibernate generate its value using GuidComb value as performance effective type of GUID values. At the end I defined how unsaved value is looking like so NHibernate would be able to deduct how the class should be persisted (insert or update)
That the FirstName property should be mapped to the column with the same name where the column length is 50 characters and null values are not allowed
That the LastName property should be mapped to the column named “SurName” with the maximum length of 50 characters without null values being allowed

In my opinion main advantages here are that the configuration code is human readable and refactoring friendly (if I ever do changes on ReferencePerson class mapping file will be broken so we have “type safe” configuration settings)

Mapping Customer

Customer class mapping definition is stored in CustomerMap (implementing the ClassMap<Customer> class looking something like this

using CustomerConfiguration;
using FluentNHibernate.Mapping;

namespace NHConfigMappings
{
    public class CustomerMap : ClassMap<Customer>
    {
        public CustomerMap()
        {
            TableName = “Customers”;
            
            Id(x => x.Id).GeneratedBy.GuidComb()
                .WithUnsavedValue”00000000-0000-0000-0000-000000000000”);
            
            Map(x => x.Name).WithLengthOf(50);
            Map(x => x.CustomerNumber).WithLengthOf(50);
            
	    HasMany<ReferencePerson>(x => x.ReferencePersons)
                .Access.AsProperty()
                .AsBag().WithKeyColumn("CustomerId")
                .Cascade.All();                        
            
            Component<Address>(x => x.CustomerAddress, 
                               m =>
                                   {
                                       m.Map(x => x.Street).WithLengthOf(100);
                                       m.Map(x => x.PostalCode).WithLengthOf(6);
                                       m.Map(x => x.Town).WithLengthOf(30);
                                       m.Map(x => x.Country).WithLengthOf(50);
                                   });
        }
    }
}

In a class constructor, I am defining:

The name of table to which this class map
Customer.Id as primary key containing guid value
Customer.Name is mapped to the Name nvarchar(50) column
Customer.CustomerNumber is mapped to the CustomerNumber nvarchar(50) column
Customer class contains collection of ReferencePerson instances stored in Customer.ReferencePersons property
which should be mapped in separate table (AsBag()) where role of FK will be performed by ReferencePerson.CustomerId
and with cascading of events (Insert of Customer will result with Insert of ReferencePerson etc)
Customer contains property CustomerAddress of type Address as embed value where
1. Address.Street is nvarchar(100) column
2. Address.PostalCode is nvarchar(6) column
3. Address.Town is nvarchar(30) column
4. Address.Country is nvarchar(50) column

Once again, take a look at the class above. I have just described something which looks like typical use case we face in real world with something which (IMHO) has very high readability and it is easy to be written

Unit testing fluent nhibernate mappings

In order to present how those mappings should be used I wrote unit test project which will present:

how this mappings are to be used
how to configure nhibernate itself without the need for hibernate.cfg.xml file

For the purpose of this test I choose MS Test just for kicks (although I am mostly using MBUnit )

How to initialize nhibernate without hibernate.cfg.xml

Due to the fact that initializing nhibernate engine is slow, I am initializing it once per text fixture and in test fixture of this example nhibernate initialization routine in case of fluent nhibernate is a 5 step procedure:

Initialize type implementing IPersistenceConfigurer (MSSqlConfiguration, SQLLiteConfiguration, PostgreSQLConfiguration are currently supported)
use instance of that type (in my example instance of MSSqlConfiguration) to preset properties of NHibernate.Configuration instance
create instance of FluentHibernate.PersistenceModel type
use that instance to load the assembly containing mappings
use that instance to inject mappings to nhibernate configuration instance

At the end of configuration sequence I have operational NHibernate configuration instance which I use to create session factory which I then store as a class field.

Once I have that SessionFactory field in place, each one of the test methods just uses it to create a session needed.

Let’s take a look at how this initialization routine could look in code

   
	
	private static ISessionFactory _sessionFactory;

        [ClassInitialize]
        public static void FixtureInit(TestContext testContext)
        {
            // initialize persistance configurer
            IPersistenceConfigurer persistenceConfigurer =
                MsSqlConfiguration
                    .MsSql2005
                    .ConnectionString.Is(
                    “Data Source=.\SQL2008;Initial Catalog=NHibernateBlog;"
		    + "Integrated Security=True”)
                    .ShowSql();

            // initialize nhibernate with persistance configurer properties
            Configuration cfg = persistenceConfigurer
				.ConfigureProperties(new Configuration());

            // add mappings definition to nhibernate configuration
            var persistenceModel = new PersistenceModel();
            persistenceModel.addMappingsFromAssembly
			(Assembly.Load(“NHConfigMappings”));
            persistenceModel.Configure(cfg);

            // set session factory field which is to be used in tests
            _sessionFactory = cfg.BuildSessionFactory();
        }

I think code above is simple enough (thanks to FNH) that it doesn’t need any extra explanations about its concrete implementation.

Nhibernate unit test method

Now when we have that session factory up and going, we would make only a simple test where we will create a new customer and try to store it in DB.

That test code could look like this:

        [TestMethod]
        public void ReferencePerson_Create_ShouldCreateRowInDb()
        {
            var customer = new Customer
               {
                   Name = “John Doe”,
                   CustomerNumber = “12345”,
                   CustomerAddress = new Address
                                         {
                                             Street = “1st Mayson Street”,
                                             PostalCode = “01754”,
                                             Town = “Maynard”,
                                             Country = “USA”
                                         },
                   ReferencePersons = new List<ReferencePerson>
                                          {
                                              new ReferencePerson
                                                  {
                                                      FirstName = “Nikola”,
                                                      LastName = “Malovic”
                                                  }
                                          }
               };

            ISession session = _sessionFactory.OpenSession();
            Guid id=(Guid)session.Save(customer);
            session.Flush();

            session.Evict(customer);
            
            var customerDB= session.Get<Customer>(id);
            Assert.IsTrue(  customerDB.Id == customer.Id && customerDB.Name == customer.Name 
                            && customerDB.CustomerAddress.Street == “1st Mayson Street”
                            && customerDB.ReferencePersons[0].FirstName == “Nikola”);

        }

At the beginning of the test method I create a new customer instance with CustomerAddress data and single ReferencePerson instance in ReferencePersons.

Then I use the sessionFactory created in test fixture set up, and create a session which then I use to persist customer instance. As a result of that persistence method call I am getting customer identity value used as PK value in DB.At the end of that persistence code I just flush the session in order to commit the changes.

Now when (hopefully) our customer is saved I need to test that and the usual way of testing save is to try to load the data from DB. That’s why I remove the customer instance from NHibernate Identity Map “cache” so I won’t get results from memory and then I am trying to retrieve data using the identity value I retrieved during persistence.

With the retrieved customer data I do just quick value check (in real world test this check would look different).

Test will pass therefore if retrieved data will match the data of customer instance created in this test.

Running the test

Once I run the test, I got successful test

And fast look at the DB shows that data are persisted

Test passed!

Conclusion

Purpose of this blog post was to present a way of using NHibernate different then the standard xml configuration approach most of people use right now working with NHibernate.

I hope you can see for yourself that it is VERY possible to use NHibernate without a single configuration file on very DEV friendly and intuitive way.

The example I presented here is just tip of the iceberg so I strongly encourage you to sync Fluent NHibernate source code and play with quick start and test projects.

Here are also some links you can check out too:

Happy Hibernating!

Technorati Tags: fluent nhibernate,nhibernate 2,PI,POCO,nmalovic

Model View Presenter (MVP) – Tips from trenches (TFT) – Working with HttpContext (Part 2)

malovicn — Wed, 30 Jul 2008 10:49:00 GMT

Today’s hurdle: Using HttpContext without System.Web One of the principles I really feel strong about can be formulated like this:”Presenter is not allowed to reference System.Web assembly at all”. Main reason why I feel so strong about that, is based on the fact that once referenced System.Web enables developers in your team to use types from that assembly (HttpContext, Session, Query, Cache etc) and we all know what PITA those types can be when testing Presenters. Here’s very simple example I’ll use in today’s post: Imagine you have a presenter which based on value of some query parameter is performing some redirecting or updating UI elements. The easiest way (referencing the System.Web into presenter) will enable very easy implementation of required functionality but testing that code will require things like creating fake web context which IMHO is good sign of of important web test smell. To check out rest of my MVP (Model View Presenter) blog post please visit my blog page (thanks to feedburner limit of 500K per feed) ...(read more)

Model View Presenter (MVP) – Tips from trenches (TFT) – Base types(Part 1)

malovicn — Sun, 27 Jul 2008 20:47:00 GMT

RAD tooling style Microsoft is supporting last couple of years usually leads to the code where presentation and bossiness logic are mixed and tightly coupled which makes testability, maintainability and sustainability much more harder then they should be. In case you’ve had to work in the past with web pages containing couple of thousands lines in code behind you will know exactly what problems I am referring to here. In case not, please let me know what is the name of the place where you work :) One way to tackle that is using the Model View Presenter UI design pattern which provides clean separation between UI and domain logic and as a result of that come testability of the “UI code”, SRP and SOC principles appliance, clean domain model etc… To check out rest of my MVP (Model View Presenter) blog post please visit my blog page (thanks to feedburner limit of 500K per feed) ...(read more)

Model View Presenter (MVP) – Tips from trenches (TFT) - Announcement

malovicn — Sun, 06 Jul 2008 07:26:04 GMT

I have blogged already in the past about MVP basics, MVP vs MVC, MVP Passive View and MVP Supervising Controller but recently I had some interesting experiences in applying MVP into real world applications and from that endeavor I learned couple of things and get answers on couple of common questions which I would like to share with community.

To me, the most interesting part of this experience was that some of my MVP based coding was done using Web Client Software Factory but part of MVP coding was done without it, so I had to “port” WCSF features to standard asp net application. I would describe pieces of that port which (I guess) would be interesting for the ones not being able to sell WCSF to their managers but still wanting to use MVP in their ASP NET development.

Another thing I would try to explain is something a lot of people don’t know: Microsoft MVC .NET framework consist of two separate parts: MVC and routing engine. In other words, routing engine is not part of MVC design pattern and it can be used with WebForms too…

Another very important thing in real world MVP development I would try to demo is how to introduce MVP pattern usage in legacy components where the legacy model is not written in decoupled manner (Separate interface, Adapter and Translator design patterns)

Last, but not the least, I would show how MVP pattern is looking combined with ServiceLocator I presented in Design For Testability blog post series and show examples on how to test MVP

Once I finish presenting all this, I would use presented concepts in showing how “one interesting "real world" example” would look like done with MVP pattern and standard WebForms

So, MVP fans stay tuned for the posts to come very fast. People not interested in MVP, please be patient… I just need to nail down MVP , “once for all” :)

Disclaimer: The purpose of this blog post series will not be showing that MVC based web development is worst then the MVP one. MVC is awesome but unfortunately requires too big investments to be introduced in existing large web forms web applications (most noticeably the need for redesigning all code which relies on page event life cycle). For those brownfield scenarios, I found MVP much easier to be implemented and adopted by webform developers then the MVC.

Technorati Tags: MVP. ModelViewPresenter,TFT,malovic

Adobe Air 2008 Tour – Prague

malovicn — Tue, 10 Jun 2008 09:56:00 GMT

For a few of you reading my blog, this blog post would most definitely come as a big surprise knowing how passionate I am about SIlverlight and all related stuff. Well, although I believe that the real thing is Silverlight, I wanted to check out how the...(read more)

Design for testability – Auto Mocking Container (AMC) – Part 9

malovicn — Sun, 08 Jun 2008 22:49:47 GMT

On my quest to design for testability, I've already covered:

Part 1 - Separation of concerns (SOC) by encapsulating DAL code in internal provider class
Part 2 - Decoupling manager and provider class (introducing the IProvider)
Part 3 - Decoupling manager from it consumers (introducing the IManager)
Part 4 - Design for testability - Dependency Injection Frameworks
Part 5 - Design for testability - Castle Windsor
Part 6 - Design for testability - Structure map
Part 7 - Design for testability - Microsoft Unity
Part 8 – Design for testability - Transparent and opaque dependencies

My today’s post would be covering AutoMockingContainer (AMC) in both “standard” and “service locator based” versions

What is auto mocking container (AMC)?

I’ll use the example from original Elutian blog post (where the concept of AMC is first mentioned) where the test setup code looks like this:

[SetUp]
public void Setup()
{
  _service1 = _mocks.CreateMock<IService1>();
  _service2 = _mocks.CreateMock<IService2>();
  _service3 = _mocks.CreateMock<IService3>();
  _serviceWeAreTesting = 
       new DefaultServiceWeAreTesting
            (_service1, _service2, _service3);
}

This example applies transparent dependency injection style described in previous post with a class expose a constructor accepting many interface parameters "(“services”) to which class functionality is dependable on. On first look, there is nothing wrong with the example above but once you would be doing serious testing you would probably find out two things:

(PIA) during test creation you would probably feel that it is too much “plumbing” code to be done to support testing
(REAL PIA) long after once the tests would be done someone would add to that class constructor another parameter (“service4”) and each one of the tests you created would start crashing although probably the functionality you were testing is not relying on _service4 at all.

To tackle those two issues, smart people at Elutian combined Rhino mocks and Windsor container to tackle those problems.

Using AMC the same test setup code would look like this:

[SetUp] 
public void Setup() 
{ 
  _mocks = new MockRepository(); 
  _container = new AutoMockingContainer(_mocks); 
  _service = _container.Create&lt;DefaultServiceWeAreTesting&gt;(); 
}

As you can see, in case of AMC we construct AutoMockingContainer with MockRepository instance thrown as parameter.

That allow’s us to replace explicit mock creation and concrete constructor invocation with AMC container Create method which accept as generic type parameter the type we plan to test.

Windsor would then find out the constructor which needs to be used and for each one of the service interfaces (if they are not in container) would create a dynamic mock class implementing given interface (thanks to Rhino mocks).

so now when we have this initialized writing the test is much simpler and looks like this (taken from the same Elutian blog post)

[Test]
public void DoWork_Always_AsksOtherServices()
{
  using (_mocks.Unordered())
  {
    _container.Get&lt;Service1&gt;().DoWork();
    _container.Get&lt;Service2&gt;().DoWork();
    _container.Get&lt;Service3&gt;().DoWork();
  }
  _mocks.ReplayAll();
  _service.DoWork();
  _mocks.VerifyAll();
}

As you can see, we are not explicitly constructing service class and registering services to container. AMC container already created instance and add components to container in setup method so all we need to do in test is to use them.

Obviously:

This is much shorter to be written –> issue #1 is solved.

Even if we would add additional constructor parameter the AMC would recognize that IService4 was added and it would add its mock to container effectively preserving the test not depending on IService4 runable –> issue # 2 resolved

(To get AMC source code which you can compile on your box and use, click here)

Auto mocking container and Unity

As I mentioned above, the AMC solution given above is for Castle Windsor IoC framework and my IoC framework lately become Microsoft Unity (due to the reasons stated in DFT Unity post), so I did little search for Unity AMC and found out that Roy Osherove implemented it already.

Roy provided in that blog post example how test looks:

[Test]
public void MockTwoDependenciesForAConstructor()
{
	MockRepository mocks = new MockRepository();
	AutoMockingUnityContainer container =
        	new AutoMockingUnityContainer(mocks);

	container.WillReturnAStubFor<ILogger>();
        container.WillReturnAStubFor<IEmailer>();

	using (mocks.Record())
	{   
		//Tell our mock to return true when this method is called
        	container.Resolve<ILogger>().IsLogFileFull();
                LastCall.Return(true);	
	}

	//runner class takes both of these mocks in its constructor
        Runner runner = container.Resolve<Runner>();
        Assert.IsNotNull(runner);
}

Well, although his implementation is VERY cool way of “create mock and inject it to container” it is not (at least how I get it) the AMC like the one Elutian guys did because I am still expected to define stubs and inject them to container explicitly (although on short&easy way) (issue #1 still exist).

But, #2 (more important one) is handled with this because test code not depending on the additional dependency wouldn’t crash.

So, all in one, if you do IoC with Unity go to mentioned Roy blog post and copy paste the Unity AMC source code for your own usage.

Auto mocking container – my way

Well, as I presented in previous post, currently the way I am writing and testing my code is that I declare internal constructor accepting the dependencies and perform mock injection without using of any IoC framework.

But, even for me issues #1 and #2 are not a big problem (I don’t mind declaring mocks and I WANT my test to crash when tested lass change so I have to check out the tests), I can imagine that for some of people this wouldn’t be the case. For them, testing on the simplest possible way with #1 and #2 resolved would be “have to” requirement.

The good news here is that there is solution for this almost “out of the box” thanks to the design decisions I made in previous posts:

I would have Facade component (ServiceLocator) encapsulating concrete IoC framework usage
Default constructor performs “poor man dependency injection” using the ServiceLocator

If we think about what the problem really is AMC tries to solve we would come up with something like this:

“When IoC container is asked to retrieve a type implementing some interface and that mapping is not defined, return a mocked instance of the interface.”

And that is exactly what I would do…

Modifying ServiceLocator

ServiceLocator class is going to support testing mode when instead of IoC container exception throwing (for cases of no type can be retrieved from IoC container for a given interface) ServiceLocator would create a new mocked instance. Something like this:

using System;
using Microsoft.Practices.Unity;
using Rhino.Mocks;

namespace Facade
{
    public static class ServiceLocator
    {
        private static readonly MockRepository _mockery 
            = new MockRepository();
        private static readonly UnityContainer _unityContainer
            = new UnityContainer();

        public static bool TestMode { get; set; }

        public static void InjectStub(I instance)
        {
            _unityContainer.RegisterInstance(instance
                , new ContainerControlledLifetimeManager());
        }

        public static T Retrieve<T>;()
        {
            try
            {
                return _unityContainer.Resolve<T>();
            }
            catch (ResolutionFailedException e)
            {
                if (TestMode)
                {
                    return _mockery.DynamicMock<T>();
                }
                throw new InvalidOperationException(“Can't resolve dependency.”;, e);
            }
        }
    }
}

As you can see service locator now has dependency to Rhino mocks (MockReporsitory class) which is ok IMHO. There is also TestMode new boolean property which represents the way to switch ServiceLocator from production to test mode. Retrieve method now puts IoC Resolve method call inside of try block. In catch block there is conditionalization based on TestMode value: in case ServiceLocator is in test mode mocked instance is returned and in case ServiceLocator is in production mode Unity exception is been bubbled up.

And that would be all what we need to do to support custom AMC.

Writing tests using custom AMC

Now when we have the AMC container done, let’s check out how the test from last blog post would look like now with custom AMC used.

Let add first additional dependency to UserManager constructor so we would have the right use case for AMC (original constructor had only one IUserProvider in which case AMC usage doesn’t have sense)

So the UserManager class would look after that modification something like this

    public class UserManager : IUserManager
    {
        private readonly IUserProvider _userProvider;
        private readonly ISomeOtherDependency _someOtherDependency;

        public UserManager()
            : this(ServiceLocator.Retrieve<IUserProvider>(),
                   ServiceLocator.Retrieve<ISomeDependency>()) { }

        internal UserManager(IUserProvider userProvider, ISomeDependency someDependency)
        {
            _userProvider = userProvider;
            _someOtherDependency = someOtherDependency;
        }

        #region IUserManager Members
        public int NumberOfUsersActiveInLast10Days(string userName)
        {
            var userCollection = _userProvider.GetUserCollection();
            var result = 0;
            foreach (var user in userCollection)
            {
                if (user.Name.StartsWith(userName) 
                    && user.LastActivity > DateTime.Now.AddDays(-10))
                    result++;
            }
            return result;
        }
        #endregion
    }

Note that constructor now have additional parameter of ISomeDependency type.

The test similar to the one from last post but this time using the AMC would look like this:

    [TestFixture]
    public class UserManagerTest
    {
        private MockRepository mockRepository;

        [SetUp]
        public void Test_Init()        
        {
            mockRepository=new MockRepository();
            ServiceLocator.TestMode = true;
        }

        [Test]
        public void GetActiveUsers_TestCaseOfZeroUsers_WouldReturnEmptyCollection()
        {
            IUserProvider userProvider = 
                mockRepository.DynamicMock<IUserProvider>();
            ServiceLocator.InjectStub(userProvider);

            using (mockRepository.Record())
            {
                Expect.Call(userProvider.GetUserCollection())
                    .Return(new List<User>());
            }
            using (mockRepository.Playback())
            {
                // using public ctor(NO EXPOSED PARAMETERS)
                var userManager = new UserManager();
                int numberOfUsers= userManager.NumberOfUsersActiveInLast10Days(“X”);
                Assert.IsTrue(numberOfUsers == 0);
            }
        }  
    }

Couple of key moments here:

In test init method I switch ServiceLocator to “test mode” –> command him to return mocks for all types not stored in IoC container in the moment of their retrieval request
In test method I am explicitly adding to ServiceLocator ONLY instance of IUSerProvider (which is related to this test) .
ISomeDependency parameter is not mentioned anywhere in the test (solution to #1)
I am using the default constructor. That is giving me the solution to #2 which looks very strange on first sight but once one would realize that behind that default constructor is ServiceLocator based poor man dependency injection things get clearer.

Again, I am aware that this approach to AMC is probably unique (I didn’t saw anything like this on the web) but I just choose to do the AMC through component design and not by some AMC framework (although that is perfectly fine choice with me too)

Conclusion

Although I like to keep things in my own hands as much as possible, I see a lot of value coming from AMC usage in writing tests for people who like the AMC idea.

For people not sure “which pill to take” there comes the list of pros and cons I found on the web (here and here)

Pros

Can be easier to maintain and write tests/Can lead to easier test maintainability.
Allows easier focus on testing interaction.
Automatic testing the services construction via the IoC container.

Cons

Speed/performance?
It could make the test a little less readable in terms of understanding what gets injected and what the actual dependencies are.

What’s next

My DFT blog post series stops here because I am getting fed up writing about unit testing and not having fun doing it is a sign for switching gears :)

I have recently some real world experience on MVP design pattern appliance in real world scenarios so I plan to write couple of posts describing my thoughts on how to solve common problems most of the people face doing MVP (tackling complexity, communication control\page, need for HttpContext in presenter, composite UI communication, Front controller routing etc) so in case you are doing WebForm classic ASP NET development and you care about testing your UI stay tuned

Useful links for AutoMockingContainer

http://blog.eleutian.com/2007/08/05/UsingTheAutoMockingContainer.aspx
http://www.ayende.com/Blog/archive/2007/06/08/The-Auto-Mocking-Container.aspx
http://blog.eleutian.com/2007/02/23/TestsAutoMockingIoCContainer.aspx

AMC custom implementation source code can be found here

Technorati Tags: AMC,AutoMockingContainer,Unity,TDD,malovic