SUGCON 2017 & Specflow Demo

Well – another SUGCON EU has been and gone and I was very proud not only to present, but to be a part of such an awesome community 😀

I particularly enjoyed:

Brian Beckham’s – “SITECORE USING PLATFORMS AT ENTERPRISE SCALE”: A great and positive insight to some of the challenges faced when really trying to push the boundaries of multi-tenant builds in the enterprise space.

Nick Hills’ – “DEVOPS WITH SITECORE IN THE CLOUD”: Thought Nick did a great job of giving real world insight into the world of cloud based devops using cases from a large scale client running on AWS.

Specflow Demo

For those who were gracious enough to watch my demo, I truly thank you. As promised, you can find the code from my demo from my Github page here:


Quick creation of a Sitecore Item to pass in unit tests

This is a super quick post.

In quite a number of test scenarios I would choose to abstract the ‘doing’ something with a Sitecore item to a repository class that could only be integration tested. This would mean that for that test scenario, generally the only necessity is to ensure that the item is not null, then rely on the repository to do the real work for me.

I recently came up with this method of creating a dummy item to enable unit testing of a method that takes an item as a parameter. Note – this is no substitute for FakeDb – but in the majority of scenarios – for real unit testing, I would be using Glass Mapper anyway.

Here is a simple method to create a test item without any app.config or anything.

Continue reading

Unit testing with test harnesses

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.

Continue reading

Allowing unit tests using generic funcs, actions or expressions

The other day, I was required during writing a unit test on a Sitecore pipeline to be able to get the value from a method in a base class in the original Sitecore API. In this case it was Sitecore.Mvc.Pipelines.Response.RenderRendering.GenerateCacheKey, and what I needed to do was get the cachekey from the base and then modify it to add additional string values to the key. In doing so I realised that the standard ‘abstract it away’ didn’t really work in its traditional form, since the abstraction would not be aware of ‘base.’. I could pass in that specific method as an argument, but felt that a better approach might be to create a utility repository that would allow me to execute code with an expected return. This meant using a normal Mock of this approach, I could abstract the code in question and simply return what I expect to be the value, without worrying about it (in this case) actually getting the API involved.

Continue reading

Using Sitecore Users in your unit tests

Hyper quick post for the morning 😀 – I have once again been tasked with security related work in Sitecore. I know there are many approaches to this – wrapping, Virtual Users (which requires dummy config) , but on this occasion (have done it a few times before too) I am not particularly interested in interrogating the user once I have finished with it – just ‘mocking’ / stubbing one as an argument or a return. So I thought I use this:

    public class TestUser : User
        public TestUser(string name, bool isAuthenticated)
            : base(name, isAuthenticated)


Works a treat 😀

Don’t Fight The Framework – Strategies to optimise Sitecore MVC Performance

After now a couple of weeks of performance optimisations on Sitecore 7.2, I thought I would detail a little bit about ways you can optimise the performance of your MVC based Sitecore solutions.

Before I go any further with this post, I would like to make it clear that I have actively engaged with Sitecore UK and Sitecore support, sent them all of my findings and made performance improvement suggestions based upon my findings. These will hopefully benefit us all in future updates and if you come to the load testing / performance optimisation phase of your project, I would highly recommend you do the same.

Below you will find a summary of the results of my findings during performance and load analysis on Sitecore. For one of my latest builds for a client, we have pretty much followed as close to best practice as we possibly could (including a site review by Sitecore themselves and actions out of it as such), we underwent load testing on the first generation of the clients new site. The site did perform to the acceptance criteria of approximate 12,000 requests a minute that is required for the site at peak time – but not by much. It also VASTLY outperformed it’s predecessor which was a Sitecore site built by a reputable UK Sitecore partner. Since the results were close to the limit though (and to allow for overhead to allow future growth) I found myself having to analyse the performance of various elements of our solution and subsequently of Sitecore itself in order to gain the maximum out of our build.

Continue reading

Life Through A Lens – Unit Testing your .net code using Glass Mapper

So now I have gotten my first couple of Sitecore User Group presentations out of the way – I thought I would actually continue on my journey of showing how I use Glass Mapper on the Sitecore platform in real world application.

As you will see from other posts I write – I am very much a TDD advocate. I find it helps focus my mind much better than simply writing code ad-hoc. Also – I hate testing, but love coding – so what better way to get my testing done than coding.

In choosing an ORM, I believe this should be one of your primary criteria since you are going to take some sort of performance hit with it being in the way and for me, trying to justify as just being ‘prettier’ code doesn’t really cut it when you are presenting it to a wider team.

With this in mind, I thought I would kinda tie these two together and look at how I use Glass to perform unit testing on *MY* code.

Continue reading

Unit Testing – Thoughts from an opinioniated developer

Getting started

Unit testing is one of those things that we know we should be doing. However, time and project pressures often result in various reasons why many don’t do it.

Having worked and consulted in a variety of teams I often find myself dealing with situations like this by asking the following questions:

  1. How do you know your software is working?
  2. How do you know if your software is broken?
  3. How do you know if someone elses change won’t break your hard work?

Generally, these are the three important questions that I try to answer when writing my own unit tests. Whether for Sitecore or not. The content of these tests is to try and prove it. Initially, writing a quality unit test can be hard. A quick search on Google will tell you that a unit test should be small, repeatable, focused and relevant.

That’s a useful guideline but we need a bit more information to get us started. To reinforce this, lets take an aside and consider a project I worked on for a major UK supermarket retailer.

In this project, the customer mandated 95% code coverage across the entire codebase. So the developers were focused on reaching this percentage and would be testing constructors and the like. More importantly they were jumping through hoops to test all their conditional branching, magic flags and so on. They were doing this
as they had code colouring turned on and could see which lines weren’t covered.

So, what to take away from this? Well firstly they weren’t writing their code to be testable. This should be our first rule:

Write your code to be testable

Next lets consider how they were getting code coverage. They were looking at how to test each individual line rather than consider what the code as a whole was attempting to do. If we stand back, we can see how the code is expected to operate under normal conditions. So that’s our second rule:

Test your code under normal conditions with expected parameters

By now we should have an idea of what our third rule should be! Now we start to think about how our code can break. What if a parameter is null? What if we have an unexpected value somewhere? We need to test the code under unexpected conditions and understand where and how it can break.

Test your code under unexpected conditions and with worse case scenarios

This is a very useful step. If for nothing else its something that you might have to cover at code review. It also means you can diagnose a production system more easily because in handling your unexpected conditions you have the opportunity to log, throw custom exceptions, raise alarm bells (and so on).

At this point, you should be in a position to have quite a reasonable level of code coverage but more importantly the tests in place are relevant, focused and they should be repeatable.

So lets consider the next rule of unit testing:

What am I actually testing?

No code sits in isolation. We access databases, save to files on disk, send messages, create pictures and so on. The list is endless. Because of this, we are always going to be calling third party code and integrating with third party systems.

So should we test them? No. Should we test our integration with them? Possibly. Should we test our calls to the integration layer? Yes. Provided we have abstracted our integration behind our own interfaces (such as a repository object or service object).

Encapsulate what ‘varies’ behind an interface, code to that interface and then write unit tests for code that depends on that interface according to the rules above. And if you only get 85% code coverage well the remaining 10% is a judgement call between you and your customer/employer!

So how do we write testable code?

Well written code is something that takes time and experience to produce. To start with testable code we could go back and cover writing code according to SOLID principles. Lets put that at the back of our minds for a moment and consider it in more abstract terms.

One method of writing testable code is to write the test first. This puts us into the mind set of thinking about how the contract will be used by calling code. Here we have an idea of our parameters, return types and the like. In fact many unit test advocates would argue that this is the only way to do it. Of course in reality it depends on where you work and how defined your designs/stories are.

Another tool on our development shelf is to consider how we might build or refactor the code internally. One example is switching on magic strings or enum values. Can we replace this with polymorphic calls and remove conditionals? If so, we can make our test cases easier to produce because we don’t have to setup our unit test to have mocked data that handles both sides of the conditional.

If we don’t do that, our test is inherently harder to write. So its slower to produce and as such a barrier to producing a unit test.

SOLID code

Part of SOLID design is to create classes that have single responsibilities. Then we create a contract for them and depend on that contract. Letting us change the behaviour of our application as long as the contract is maintained. In a unit testing scenario, this lets us insert fakes/mocks more easily.

In writing testable code its important to strike a balance point between breaking the problem up into contracts you depend on and having an explosion of classes. One code smell is a constructor with many dependencies. If you are in this situation its not always bad – but for greenfield code its certainly something you should look at and review with colleagues.

Not only does this make your unit test harder to setup it can also mean your interface contracts are not fit for consumption. At the lowest level in your API, this is fine but as you go up towards the consumer I strongly recommend that the interfaces define key application ‘operations’ rather than lots of smaller methods.

This is obviously project dependant and some projects you want a simple external interface and in others you don’t. But even so, its worth having at the back of your mind.


These are just some of my thoughts about unit testing and how it relates to software design. I’ll follow these up with some thoughts on designing your software and my take on bottom-up vs top-down design and how that affects your project scalability.

Don’t Fight The Framework – Unit Testing On Sitecore Pt I

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.

Continue reading