Interesting moment came when he wanted to see if his service actually works. He quickly created another project (Windows Forms) to try connect to newly created service. When I’ve seen that I’ve suggested that a unit test project would be easier and more useful, he preferred to go his route and added buttons, large text block and some plumbing code to take service’s response to the screen.

I’m not blaming here (as he is rather new to .NET platform), but his approach has few disadvantages versus verifying a service using unit tests:

• it’s slower to create a minimally meaningful solution: a crappy screen with a button “connect” and large text box to see results? I’d prefer a test with an assertion and may be some console output
• it’s slower to analyze results: you have to scan the screen to see/analyze replies. I’d prefer that a test assertion would take care of that.
• it’s error prone: you have to rely on human input to test it. I’d prefer an automated approach.
• it’s not repeatable nor scalable: what if you have second service? 10 methods in service?. I’d create new test fixture and refactor existing code, not UI.
• …

… lot’s of things that are wrong with this approach.

Even if it’s a short living spike, new project, new feature – whatever needs a proof of code in working state – I’d prefer to write a test for it. And I’m not talking here about rigorous Test-Driven-Development approach. It’s more like acceptance testing at service or component boundaries, only to be sure that it works as expected. And creating an UI just to see that a service works – it sounds wrong to me. But those are “cultural differences”, I think…

PS: By “cultural differences” I mean past experience, habits, education, professional environment and so on…

That was the case when I’ve seen earlier in Tuna Toksoz‘s weblog a description of “hbm2ddl.auto” property. Few days ago, I’ve put it to work in a way that makes me feel better. By the way, the particular reason that made me happy was that I’ve deleted a lot of repetitive code from our code base.

How you can use hbm2ddl.auto property in unit tests

Our integration tests are run over a real database. For each test we’re re-creating the database, so that each test will be ran in separation and without interfering with results of previous tests. Also, things are a bit complicated since we’re working with few databases at the same time, each with his own schema. Before, each test had to use SchemaExport class that exported the database schema built from NHibernate configuration on the way deleting your old database/schema/data. So, each integration test class had same method to call. Redundant and repetitive. Yes, you can make a base class that will do that, but you have to inherit then all tests from that class.

How it works now: in session configuration (usually in app.config for integration test project) you put:

<property name=”hbm2ddl.auto”>create</property>

… and you’re set. Each time your code will build a new SessionFactory, NHibernate will call:

new SchemaExport(cfg).Create(false, true);

This way, before the SessionFactory will be built, your database will be refreshed with a new schema and tests will run in a clean database.

One line of code instead of tens or hundreds. Isn’t that a good trick?!

A word of warning – don’t let this code escape to your production code. It may be dangerous… But, you know that, we’re running with scissors…

In code, it looks like this:

  1: [Transactional]

  2: public class Foo

  3: {

  4:     [Transaction]

  5:     public virtual void Bar()

  6:     {

  7:         // Do something in a transaction

  8:     }

  9: }

 10: 

Let’s suppose that later, we want to test this code. Say, we want to verify that code in Foo.Bar() method is executed in a transaction. Moreover, we want to assure that the marking attributes will not be deleted accidentally.

We can test that within two aspects. First – an integration test: a real application part will be spawned and a call will be performed. After, we should verify that changes was committed by transaction. It takes time to run such a test (integration test usually runs slower) and effort to write & verify such a test. Second way to test that – is to check presence or required attributes. This will be a fast unit test that will just check that attribute is still applied to a method.

Those methods complements each other. Ideally, it should be both written.

Let’s see how we can verify that attributes required by ATM are applied to required methods.

First, we’ve defined the API that we want to use to do our check:

  1: CustomAssertions.ShouldUseATM<Foo>(foo => foo.Bar());

Yes, you see it right, we want to make it type save, refactor-able and nice looking.

This helper class should verify next assumptions, all required by ATM:

• Tested class should be marked with TransactionalAttribute;
• Method should be marked by TransactionAttribute;
• Method should be virtual.

Solution we came to this problem is the next class:

  1: public static partial class CustomAssertions

  2: {

  3:     public static void ShouldUseATM<T>(Expression<Action<T>> methodExpression) where T : class

  4:     {

  5:         ThrowIfTypeNotMarkedAsTransactional(typeof (T));

  6:

  7:         var methodInfo = ((MethodCallExpression) methodExpression.Body).Method;

  8:

  9:         ThrowIfMethodIsNotMarkedWithTransactionAttribute(methodInfo);

 10:         ThrowIfMethodMarkedWithTransactionAttributeIsVirtual(methodInfo);

 11:     }

 12:

 13:     private static void ThrowIfTypeNotMarkedAsTransactional(Type classType)

 14:     {

 15:         object[] foundAttributes = classType.GetCustomAttributes(typeof (TransactionalAttribute), false);

 16:         if (foundAttributes.Length == 0)

 17:             Assert.Fail("The type '{0}' is not marked with [Transactional] attribute", classType.Name);

 18:     }

 19:

 20:     private static void ThrowIfMethodIsNotMarkedWithTransactionAttribute(MethodInfo info)

 21:     {

 22:         var found = info.GetCustomAttributes(typeof (TransactionAttribute), false);

 23:         if (found.Length == 0)

 24:             Assert.Fail("Method '{0}' from '{1}' type is not marked with [Transaction] attribute",

 25:                         info.Name,

 26:                         info.DeclaringType.Name);

 27:     }

 28:

 29:     private static void ThrowIfMethodMarkedWithTransactionAttributeIsVirtual(MethodBase methodInfo)

 30:     {

 31:         if (methodInfo.IsVirtual && !methodInfo.IsFinal)

 32:             return;

 33:

 34:         Assert.Fail("Method '{0}' from '{1}' type is marked with [Transaction] attribute, but is not declared as virtual.",

 35:                     methodInfo.Name,

 36:                     methodInfo.DeclaringType.Name);

 37:     }

 38: }

 39: 

So far, we’re pleased with how it works for us.

Can_resolve_all_services_in_container()

Bill Simser wrote some time ago about the first test to be written when using Castle’s Windsor Container. It’s a real gem that let’s you verify if any of services registered in container can be resolved (have all required dependencies). Here is it, a bit improved for skipping verification for generic types, since, at that moment, we don’t know the generic argument for type to be constructed:

[Test]
public void Can_resolve_all_services_in_container()
{
    var container = new WindsorContainer("container.xml");
    foreach (IHandler handler in container.Kernel.GetAssignableHandlers(typeof(object)))
    {
        if (handler.ComponentModel.Service.IsGenericType)
            continue;

        container.Resolve(handler.ComponentModel.Service);
    }
}

Can_compile_NHibernate_mapping_configuration()

This test was sitting for a long time in our codebase, but I’ve seen it recently in this post of David Larebee. I wrote it in times when writing our first mappings and the only one way to verify if you don’t have any faults was to write one of CRUD operations and run the test. But that’s a long process. Shorter response cycle is always better. Here it is:

[Test]
public void Can_compile_NHibernate_mapping_configuration()
{
    ISessionFactory factory =
        new Configuration()
            .Configure()
            .AddAssembly("MyApp.MyDomainAssembly")
            .BuildSessionFactory();

    Assert.IsNotNull(factory);
}

This test suppose that you have HNibernate configuration in your app.config and tries to register all mappings from given assembly file.