Wednesday, December 3, 2014

Just Released: Chill 2.0

It took a bit longer than I had hoped, but I’ve just released Chill version 2.0.

What’s new:

  • New plugins available: Unity and UnityNSubstitute.
  • Cleaned up plugin discovery and selection mechanism.
  • PCL support (Many thanks to my colleague Dennis Doomen).
  • Automatic Mothers.
  • Using non-mocking containers for integration testing.
  • Many small usability tweaks.

Please: Check it out at : 

Will post more information shortly.

Wednesday, November 5, 2014

Using different containers with Chill

When Chill 1.0 wanted to know which container (for example the Chill.AutofacNSubstitute container) it needed to use, it would scan your loaded assemblies for types that implemented the IChillContainer. While this worked, it also posed several issues.

For one, you couldn’t use different types of chill containers. For example, if you wanted to have tests with several containers that do automocking, some without automocking, some with very specific registrations set up), you couldn’t do that.

The other issue had to do with portable class libraries. I wanted to make Chill a portable class library. For example if you wanted to test Xamarin IOS classes (without turning them into PCL’s), then you can only reference PCL’s or Xamarin IOS dll’s from your test project.

But, to turn Chill into a PCL, I had to change the way it did assembly scanning. PCL’s have quite a lot of restrictions with regards to assembly scanning.

However, I think the end result is quite elegant.

Basically, if you install a specific container, Chill will add an assembly level attribute, in a file called DefaultChillContainer:

// This attribute defines which container will be used by default for this assembly

[assembly: ChillContainer(typeof(AutofacNSubstituteChillContainer))]


This tells Chill to use this container (in this case an AutoMocking container using NSubstitute) as the default container. Now, if you want to use a different container in some situations, you can override this on a per test basis:


public class When_configuring_container_with_module_and_objectmother : GivenWhenThen

Under the covers, Chill will wrap the container you specify in a AutoMotherDecorator (more on AutoMothers in a later blog post). If you don’t want this, then you can specify a custom ChillContainerInitializer:



The DefaultChillContainerInitializer is the class that wraps the ChillContainer the AutoMotherDecorator, so you can implement your own class if you don’t like this behavior. Now I don’t expect that this happens often, but it’s nice to have the option.

As always, keep it cool, keep it Chill!

Integration testing with Chill


Unit testing means testing software components in isolation. This can be a powerful technique to validate some complex pieces of logic.

However, if you follow the Single Responsibility Principle, you’ll find that many of your components hardly contain enough logic to warrant unit testing. For example, a webapi controller might just take a message object, validate it using a validator component, map it to an internal data format, and then hand it off to yet another component for validation. All it does is chain some components together. If you dogmatically try to unit test each of these components in isolation, you’ll end up with a system that becomes difficult to architecturally.

In those cases, integration tests make much more sense. You want to make sure that the entire collection of components work well together, not that each individual piece does what it needs to do.

Note, unit tests do make a lot of sense for some (sufficiently complex) components. As always, it’s important to know what technique to apply when.

Integration testing does have it’s own set of challenges. Ideally, you’d like to start with a pristine environment, prepare a certain ‘start situation’, then execute a test and validate the result. In the next couple of weeks, I’ll put out a sample application that demonstrates some of these capabilities.

But for now, I can demonstrate how you can setup a container in exactly the same way that you’d do in your application.

Suppose you have several registrations you’d like to make in your container. Here, I’m doing that in Autofac in a module:

   2: public class CustomAutofacModule : Module
   3: {
   4:     protected override void Load(ContainerBuilder builder)
   5:     {
   6:         builder.RegisterType<TestService>().As<ITestService>();
   7:         builder.RegisterType<TestSingleton>().SingleInstance();
   8:         base.Load(builder);
   9:     }
  10: }

Ok, great.. now how would you set up a chill container that uses this? The easiest way is to create a custom container, that derives from  AutofacChilContainer. 

   1: /// <summary>
   2: /// You can define 'non mocking' with all the type registrations that you would otherwise in your application. 
   3: /// This can either be done in the App. This class also creates a single 'parent' container and then child containers
   4: /// per test. 
   5: /// </summary>
   6: internal class AutofacContainerWithCustomModule : AutofacChillContainer
   7: {
   8:     private static ILifetimeScope staticContainer;
   9:     private static object syncRoot = new object();
  10:     public AutofacContainerWithCustomModule()
  11:         : base(CreateContainer())
  12:     {
  14:     }
  15:     /// <summary>
  16:     /// This method creates the Autofac container and registers the custom type 
  17:     /// </summary>
  18:     /// <returns></returns>
  19:     private static ILifetimeScope CreateContainer()
  20:     {
  21:         if (staticContainer == null)
  22:         {
  23:             lock (syncRoot)
  24:             {
  25:                 if (staticContainer == null)
  26:                 {
  27:                     var builder = new ContainerBuilder();
  28:                     builder.RegisterModule<CustomAutofacModule>();
  29:                     staticContainer = builder.Build();
  30:                 }
  31:             }
  32:         }
  33:         return staticContainer.BeginLifetimeScope();
  34:     }
  35: }

This way, Chill will setup your Autofac registrations once. Very welcome if you’re registering expensive things such as NHibernate SessionFactories. It will also setup up two lifetime scopes. One per test run (since it’s a static singleton) and one child scope per test. This child scope can be customized to your hearts content.

Now if you wish to use this container, you can set the following attribute on class or assembly level:


Chill 2.0 beta released

I’ve just released a beta for Chill 2.0. What’s new?

  • Support for Integration testing using Autofac (no mocking).
  • Support for multiple Chill containers in a single assembly. Ideal if you want to have both integration tests and unit tests in a single assembly.
  • Support for automatic object mothers.
  • Chill is now also available as portable class library (thanks for that Dennis)!
  • Several usability tweaks.

Get the changes via Nuget:

Install-package Chill.Autofac –IncludePrerelease

Install-package Chill.AutofacNSubstitute –IncludePrerelease

Install-package Chill.AutofacFakeItEasy –IncludePrerelease

I’ll blog further about these improvements soon. As always feedback is very welcome.

Keep it Chill!

Monday, October 13, 2014

Async testing with Chill

Let’s face it. Async programming is difficult.

The Async Await certainly helps to make the asynchronous code more readable. Along that lines, Chill attempts to help to make your tests more readable as well.

Assume the following simple example. You have an asynchronous webapi controller. Why is this controller async? Let’s assume it needs to do IO. In this case, this is encapsulated in an async call to ICustomerStore.GetCustomerAsync().

   1: public class When_retrieving_existing_customer_async : 
   2:     GivenSubject<CustomerController, View>
   3: {
   4:     const int customerId = 12;
   6:     public When_retrieving_existing_customer_async()
   7:     {
   8:         Given(() =>
   9:         {
  10:             SetThe<Customer>().To(EntityMother.BuildACustomer()
  11:                 .With(x => x.Id = customerId));
  13:             // The GetCustomerAsync method needs to return a customer Asynchronously
  14:             // So it needs to return a Task<Customer>. The .Asynchronously() extension
  15:             // method conveniently wraps the customer in a task that returns the Customer for you
  16:             The<ICustomerStore>()
  17:                 .GetCustomerAsync(customerId)
  18:                 .Returns(The<Customer>().Asynchronously());
  19:         });
  20:         // When() also works nicely with asynchronous actions. 
  21:         When(() => Subject.GetAsync(customerId));
  22:     }
  24:     [Fact]
  25:     public void Then_view_is_returned()
  26:     {
  27:         // Even though the GetAsync() method returns a Task<View>(), the Result
  28:         // Property is still a View. This allows for easy unit testing. 
  29:         Result.Should().NotBeNull();
  30:     }
  32:     [Fact]
  33:     public void Then_model_is_the_existing_custmoer()
  34:     {
  35:         Result.Model.Should().Be(The<Customer>());
  36:     }
  37: }

In Chill, you can just define an asynchronous method in your call to When(). Chill will take care of handling the asynchronous complexity for you. Now all you need to do is to make sure your dependency return a Task instead of the ‘normal’ result. You can do this by calling the .Asynchronously() extension method.

Friday, October 10, 2014

Chill and the AutoMocking Container

One of the most important ways on how Chill helps with unit testing is by using an auto mocking container.

Compare the following code snippets:

   1: [TestMethod]
   2: public void TestWithoutTheChillFactor()
   3: {
   4:     // You have to explicitly create mocks for your dependencies 
   5:     // and store them in variables.
   6:     var mockCustomerStore = Substitute.For<ICustomerStore>();
   8:     // Also, you have to explicitly create a variable for your test data. 
   9:     var expectedCustomer = new Customer()
  10:     {
  11:         Name = "Erwin",
  12:         Address = "At home",
  13:         Id = 123
  14:     };
  17:     mockCustomerStore.GetCustomer(123).Returns(expectedCustomer);
  19:     // Also, you have to explicitly create the subject under test and insert the mocked dependencies. 
  20:     // Need to add or remove a dependency? prepare yourself to modify ALL your test. 
  21:     var sut = new CustomerController(mockCustomerStore);
  24:     // Call the actual function.. but you also have to create a variable to store your tests. 
  25:     var result = sut.Get(123);
  27:     // Multiple asserts per test? 
  28:     Assert.AreSame(expectedCustomer, result.Model);
  29:     mockCustomerStore.Received().GetCustomer(123);
  30: }

There are a lot of things wrong with this example:

  • The knowledge about which dependencies by your Subject are needed are duplicated among all your tests.
  • In each test, you'll have to explicitly create mock objects. This clutters your test with code that does add any value.
  • Multiple asserts per test make it more difficult to figure out what exactly goes wrong.
  • No explicit structure to this test. What exactly is setup code.
  • Even though most tests use a subject, a result and variables, the naming of these variables will be very different across different tests by different authors, making them more difficult to understand.

Compare this with a Chill example:

   1: public class When_retrieving_existing_customer : GivenSubject<CustomerController, View>
   2:     {
   3:         const int customerId = 12;
   5:         public When_retrieving_existing_customer()
   6:         {
   7:             Given(() =>
   8:             {
   9:                 // Storage for data used in the test. No need to create fields or variables. 
  10:                 SetThe<Customer>().To(EntityMother.BuildACustomer()
  11:                     .With(x => x.Id = customerId));
  13:                 The<ICustomerStore>().GetCustomer(customerId).Returns(The<Customer>());
  14:             });
  16:             // Subject under test is created automatically and accessable via the Subject property
  17:             When(() => Subject.Get(customerId));
  18:         }
  22:         [Fact]
  23:         public void Then_view_is_returned()
  24:         {
  25:             Result.Should().NotBeNull();
  26:         }
  28:         [Fact]
  29:         public void Then_model_is_the_existing_custmoer()
  30:         {
  31:             Result.Model.Should().Be(The<Customer>());
  32:         }
  33:     }

The automocking container sets up your Subject and automatically injects mock objects for any dependencies it needs. This is great if you have many tests against the same subject and you need to add a dependency. Your tests might fail, but that's exactly what you want. But they still compile and run!

There is no need to explicitly create mock objects anymore. The The<> method will create, register and return a mock object for you, ready for use.

If you want to explicitly register a value, you can use the SetThe<>().To() method to an object. There is also a shorthand for this: UseThe().

Note the use of the .With() extension method. This simple little extension method makes it easy to modify objects afther they have been built, in a very clean way.

Asp.Net Redirect and ThreadAbortException

Today I ran into an issue that I hadn’t seen in a long time. I was asked to diagnose two errors. “Cannot Redirect after HTTP headers have been sent”, and some random “Object Reference not Set” errors.

After analyzing some of the logs, I found that they were always found after logging out. Digging further, I found this statement: Response.Redirect(url, false);

For those who might not know, the ‘False’ parameter causes a ThreadAbortException. Why? To make sure your requests ends immediately after that.

At first, I was tempted to ‘just’ change the parameter to ‘true’ and be done with it, but I wanted to know why one of my colleagues made this change. And interestingly enough.. it showed up in the history: “added ‘false’ parameter to prevent ThreadAbortException in the logs”. So, one of my colleagues probably found his logs were full of ThreadAbortExceptions. So he avoided the exceptions and now the logs were full of other, more cryptic errors.

So I figured out the best solution would be to make sure this ThreadAbortException was not being logged. It turns out that this exception already doesn’t reach the Global.asax Application_OnError method. So that wasn’t the source of the logging. it turned out that we had some exception handling logic built ourselves. So, adding a check to see if this was a redirect solved the issue. A little extension method Exception.IsCausedByRedirect() made the code a bit more readable:

   1: public partial class _Default : Page
   2: {
   3:     protected void Page_Load(object sender, EventArgs e)
   4:     {
   6:     }
   8:     protected void myButton_OnClick(object sender, EventArgs e)
   9:     {
  10:         try
  11:         {
  12:             Response.Redirect("About.aspx");
  13:         }
  14:         catch (Exception ex)
  15:         {
  16:             if (ex.IsCausedByRedirect())
  17:             {
  18:                 Debug.WriteLine("Redirecting to: " + Response.RedirectLocation);
  19:             }
  20:             else
  21:             {
  22:                 Debug.WriteLine(ex);
  23:             }
  24:             throw;
  25:         }
  26:     }
  27: }
  29: public static class ExceptionExtensions
  30: {
  31:     /// <summary>
  32:     /// Returns if an exception is caused by a redirect. A redirect throws 
  33:     /// a ThreadAbortException (normal behavior to stop execution). However
  34:     /// this exception typically shouln't be put in the logs. 
  35:     /// </summary>
  36:     /// <param name="exception">The exception to check</param>
  37:     /// <returns>True if this exception is caused by a redirect. False if not. </returns>
  38:     public static bool IsCausedByRedirect(this Exception exception)
  39:     {
  40:         return exception is ThreadAbortException &&
  41:             HttpContext.Current != null &&
  42:                 HttpContext.Current.Response.IsRequestBeingRedirected;
  43:     }
  44: }