Making EPiServer code testable – the role of the community

As I mentioned briefly in my last post I don’t think EPiServer have been under a lot of pressure from the community to make the core product (unit) testable. And while it would be nice if this was top of the priority list at the development team it’s not very realistic. Given that this series of posts will focus on what can be done today and hopefully raise some awareness so that more people bug Epi about this topic.

Joel Abrahamsson, while most known for his absolutely despicable taste in choice of radio stations, has create a few frameworks under the umbrella of EPiAbstractions that makes testing easier. Inspired by this, I thought I ought to step up too and try to contribute something to the community. But first the disclaimer.

The Catch-22 of writing about unit testing

The big problem I find with writing about this topic is that there’s largely two groups of people. Those who knows about unit testing and how to apply it and those who don’t. It’s very easy to fall into the trap of writing something that says nothing new to those who already applies it and still seem totally alienating to those who don’t. To make it more interesting, many people who do understand testing see the test themselves as a bi-product of other means, like good architecture or as a way to drive the design.

Personally my view of tests have evolved from “something I must do because all the cool kids are doing it” via “omg, how can I test this httpcontext” followed by “ah, SOLID makes sense and how did I live without IoC-containers” to today where I view the test primarily as documentation and a driving force for my code.

My aim here is to just try and write something that I feel that I would have found useful or at least intriguing from around two and a half years back and forward. If you find it to your liking, great. Otherwise, sorry for wasting your time.

The plan

This is mostly just for me so that I know what I had originally planned as well as to put some pressure on me to actually write something.

1. A quick introduction to the tools we’re going to be using; NUnit, Moq and MSpec.

2. A discussion about different “patterns” and concrete tests to the fallback language method discussed in earlier posts.

3. Refactoring (some of) Fredrik Vigs extension library EPiCode.Extensions to be testable and also write tests for it.

4. A sample site written in EPiMVP and what the MVP pattern means for your testability. This will also be used for an introduction to web testing using Watin or Selenium.