Life Through a Lens – Unit Testing with Glass Controllers

Never let it be said that I like unit testing 😛

With the release of Glass Mapper 4.0.3 I am pleased to shout out that we have made some improvements to the unit testability of both GlassController & GlassUserControl. In addition we have also made some additional helper derivatives to make your awesome development lives even more awesome. You can find out more about the other improvements in the Glass Release Notes

In this post, I will cover some of these changes and show how you can now use GlassController in your unit tests effectively.

Basic Unit Testing Scenario’s

Here are a few gists of how you can set up unit tests using the latest version of Glass which you could use to ensure your controllers are doing as they are supposed to!

Mocking the Glass Controller Data Source –

Mocking the Glass Controller Context –

Mocking the Glass Controller Layout Item –

It is worth noting that if you (hopefully don’t) use the ContextItem, LayoutItem or DataSourceItem properties in your code, then these will remain non-testable. We have made an architectural decision to leave them in for legacy support and ease should you require them.

Note: In testing the behaviour of GlassController, we have also tried to ensure that the behaviour is consistent whether you are using rendering parameters, datasources or the context item as a base for your data. Please check when upgrading, that your code expects any of these to give a null if there is no data set for them. This should have been the case in previous versions in any case.

Unit Testing the Glass Controller Http Context

In addition to helping out with your Glass Mapper based unit testing, we have even added support to allow you to inject your own HttpContext. So when using HttpContext.Request – you can mock this too!!

Mocking the Glass Controller Request Object –

Typed Glass Controllers

Another new feature is a simple extension on our previous GlassController implementations.

In the majority of cases when you are dealing with a controller in Sitecore, you will generally be dealing with a rendering. That rendering in turn will often (but not always) expect to be dealing with one of two scenarios:

A context item or datasource item that are interchangeable – represented by the same Glass mapped class or interface.


A context item that is a different implementation to its data source.

As a useful helper, we considered it would be helpful to allow developers to specify this upfront and therefore have a basic lazy-loaded implementation for use in the controller. For this reason, we have introduces derived types of the GlassController you know and love with type parameters – so:

GlassController can be used for implementations that expect the datasource and context items to be interchangable

GlassController can be used for implementations that expect the datasource and context items to be different. This implementation though has no Layout property since the context and datasource are not expected to share a type.

These new controller types extend the original GlassController, so still have access to GetContextItem(), GetLayoutItem() and all of the other methods.

Single type Glass Controller:

Unit Testing Typed Glass Controllers

Obviously it wouldn’t be right if we didn’t keep up the unit testability, so here are a couple of gists to show how you can unit test these newer controller types too.

Gists for these new types can be found here

Mocking the DataSource on GlassController –

Mocking the Context item on GlassController –

One thought on “Life Through a Lens – Unit Testing with Glass Controllers

  1. Firstly can I say thanks for this it has been really helpful in allowing us to Test Drive our GlassController based controllers.

    I must admit however I feel it would be more helpful from a TDD view if the base GlassController exposed HttpContextBase and RenderingContextWrapper properties as public properties rather than me having to delcare an extra constructor and pass them as parameters to base just for testing. I don’t feel comfortable with this as its putting code into the production enviroment soley to support my testing.

    What are your thoughts ?

Leave a Reply to atouchofcore Cancel reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s