Test-Driven Sitecore

Earlier this evening, I had the opportunity to talk to the New England Sitecore User Group about a topic of deep interest to me - Test-Driven Development (TDD) within Sitecore. This post contains a quick recap of the talk and includes links to various resources on the subject. The slides to this talk are available on Slideshare.

I started out by discussing the key benefits of TDD as an approach it:

1. ensures code stays in a working state,
2. encourages good design, and
3. perhaps most importantly, the Red/Green/Refactor cycle allows developers to think about requirements, implementation, and design separately

I have personally found this mental "separation of concerns" very powerful, as it prevents a developer from getting lost in complex requirements, and makes sure the simplest implementation of a given item is achieved first before it is refined further. In short, it makes sure you are doing the right thing and that you start out doing it as easily and quickly as possible.

Unfortunately, it has been difficult to practice TDD on the Sitecore stack due to the lack of support for the light-weight objects that make unit testing feasible.  This has changed recently with the advent of Sitecore MVC and Object-Relational Mapper (ORM) frameworks like Glass Mapper. In the talk, I walked developers through the process of building a navigation bar using TDD with Sitecore MVC, Glass and the Autofac Inversion of Control framework, and showed how tests can be used to explore and extend delivered functionality.  This combination of Glass, Autofac, and Sitecore MVC has become the Velir standard for building Sitecore solutions in a flexible and testable manner.

I also looked at two alternatives to this approach and the associated advantages and disadvantages with each. First, the Sitecore.FakeDB project, which allows writing unit tests for legacy Sitecore solutions built on WebForms without an ORM. Second, the CodeFlood Test Runner, a browser based integration tool that was developed by Sitecore developer Alistair Deneys, to build the Revolver command line tool.

Finally, I wrapped up the talk by discussing how to get started with TDD.  Rather than going all in (and having awkward conversations with your project manager), I recommended carving out an hour a week and pairing up with another developer to write some code, test first.  As the habits and skills get stronger and the benefits of working with code with good coverage become clear, it will be an easier lift to extend this time gradually so that it eventually becomes the norm.  I also recommended setting up a TDD Kata workship and explained how to do TDD Ping Pong. Yes, that's a thing!

Make sure to stay tuned to this space for a video recording of the event and a link to a copy of the slide deck. In the meantime, you can look at some practice runs of my TDD demos here: bit.ly/tdd-videos. Feel free to comment below to keep the conversation going.