One thing I have noticed from many developers when setting up unit tests is that they like their Setup() methods. This is fine for example (shameless plug) if you are looking to integration test against something like Glass Mapper for Sitecore and want to initialise the configuration before you run your test. However, all too often, I see it used to set up things like mocks, and its this that I disagree with. So I guess for want of a better term – I created what I will (I think it’s probably technically a Builder pattern really) a ‘Test Harness’ pattern.
I’ve had the opportunity to tinker in the depths of the WebAPI in Sitecore 7.5 and 8 recently. I’ll put up a post about setting up controllers easily shortly but until then I thought I’d share how to setup IOC.
In a normal WebAPI environment, we can create our resolver and attach it to the GlobalConfiguration. However, we must remember that Sitecore uses its own pipelines for MVC and WebAPI and so setting this up in the Global ASAX won’t work.
The way I’ve done it is to change the registered WebAPI initialiser class in the Sitecore.Services.Config file found in App_Config/Include. This lets me hook directly into the entry point for Sitecore related WebAPI and adjust the configuration accordingly.
This is the first post in a series about back to basics. All to often I come across Sitecore projects that commit a number of sins. Hopefully this will tie together with the continuing series on working with the Sitecore platform instead of against it. So with that in mind, the first few parts will be about field validation in Sitecore.
Field validation is often overlooked. I think in part because the template editor has a quick and dirty interface for setting all the common properties such as name, source, shared etc. But to setup the validation, help text and the like you have to go into the field itself.
However, the content editors experience can be greatly enhanced with good validation with clear, concise error messages. It also means that as developers, we can enforce a little safety in our environment and increase our chances that our code will get data in the right ‘shape’.
A short history lesson
Before Sitecore 5, validation was done with regular expressions and a generic error message. This would fire and the user would see a popup with that message. After a while this would get pretty annoying as the editor couldn’t really see which fields were invalid and, in some cases, the warning wasn’t a critical error. Inevitably, unless all of the fields were required and the error messages could be made verbose enough, validation was turned off.
Even now Sitecore 7.x supports this functionality but using it is an incredibly bad idea.
Sitecore validation done right
Validation done right means you need to use the validators built into Sitecore (or add your own) using the various multi-lists directly on the field item for your template. If you do so, you have the advantage that as the editor builds their content, they get visual cues as to which field is incorrect. This appears as a red bar next to the field and colour spots to the top right (in the content editor). You also have the advantage that you can set the levels of these errors and class some as critical meaning the user can’t progress without fixing and you can make others ‘a bad idea’.
More importantly, these are all written in .NET code. What this means is that when you write your own, you’ll be able to unit test them under various conditions and more easily have them as part of your continuous integration builds.
This post was particularly short as an introduction to validators but they are more of a ‘show me the code’ topic. Its also pretty near to Christmas and I have small people to entertain! 🙂
In my next post on this topic, I’ll look at writing a very simple validator, registering it with Sitecore and setting its error level. More importantly, we’ll look at making it have different options per language and so handle some interesting scenarios. We’ll also have a unit test setup for it and I’ll put it on Github for reference.
Before I can proceed on in the Life Through A Lens series of blog posts, I thought I would cover something that has been somewhat of a bug bear of mine since I started working on the Sitecore platform, this is Unit Testing. I wanted in particular to address some of the misconceptions with unit testing and on using Glass Mapper in unit test scenarios. I have been using TDD (and as we all do Test After Development) since around 2007 and have learned a lot in this time. Due to this – I have decided to write this post before continuing with the Life Through A Lens Series to give a backdrop of what I feel is a key idea behind unit testing. I feel it is really important to cover off some of the classic TDD mistakes before I get involved with actually demonstrating how I use Glass Mapper to solve some of these problems.
I will before I go any further give a massive nod of the cap to Simon in his improvement of my knowledge in this area. I did know some things on this subject, but his patience and teaching allowed my knowledge to progress significantly beyond where it was at a rate quicker than it would have done otherwise.
Ok, so with the above in mind, I will move on to some of the most common phrases I hear from developers / managers ( / whomever ), these are usually in response to my first day questioning of ‘What unit test / mocking frameworks do you guys use?’. The answer of ‘none’ ( I don’t know why ) still offends me.
As a few of might already know, we started a project a short while back to overcome the difficulties developers face when building reusable modules for systems. This project was centered on the need to continually write our inverted dependency calls manually to avoid ties to an IoC container such as Autofac / Windsor. Recently a client of mine and also a friend have independently approached me about this subject. The former wants to commission me and Simon from the team here, to help them out on a build for a client of theirs, this client has asked that we use Autofac as the dependency container and Glass Mapper as the ORM. The second wants to be able to use Glass Mapper with their current implementation, they however use structure map.
It would have been a reasonable enough task to duplicate and modify the Windsor implementation from github twice to allow this to happen, but I fancied a challenge and thought this would be a good test of the Agnostic IoC extensions that I have written and talked about Here. After all, it is the near perfect use case for such an implementation – 1 framework with a choice of end IoC containers depending on the client.
What is Agnostic IoC?
Agnostic IoC is a set of extensions that aims to abstract the IoC container away from the final consuming implementation, you write your code against Agnostic IoC and it adapts the calls to the real IoC. You can initialise it from self discovery on adapters or simply push in your own already built container. It in many cases will not replace your own IoC implementation, it’s primary focus is to allow you to ship your reusable modules so others can enjoy them without tying them to particular versions of IoC containers. If the IoC container of your choice isn’t supported, it is quick and easy to write an additional one simply by inheriting from the abstract ContainerManager class. When consuming the application, you simply need to install the nuget package that matches your chosen IoC. If you need to get at any of the original functionality – the ContainerAdapter is a generic in its own right, you can simply cast something like myContainerManager.Container as IWindsorContainer to get back to the original container (that said – you can push your own in so not sure how much use it will be 😉 )
Some time ago I decided that Autofac was my IOC of choice. After spending a few years using Unity I knew I wanted more and, after evaluating a few libraries, Autofac fitted how I work.
Aside from the usual property and constructor injection stuff we would expect from any IOC library, Autofac has quite a few additional features that can make coding life a lot easier. And in less lines of code.
One thing I love to show people who have used IOC for a while is my use of delegate factories.
The wiki post from the Autofac project is here: https://github.com/autofac/Autofac/wiki/Delegate-Factories.
I think the title says it all!
Let components create instances of other components without hand-coding factories.
So, in short, we can use Autofac as a factory and take a dependency on that factory instead of the type itself. This is quite powerful as it means we can create instances of our dependency within our component as needed.