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

Did you really mean .Controller() in Sitecore MVC?

Real short post this one, but I have seen this a few times from different developers, so I am now considering that this is a common mistake and can be disastrous for performance.

The mistake is this – developers using code like the following:

@Html.Sitecore().Controller("ControllerName", "MethodName");

This code is fine and dandy IF you want to execute a controller with frills. HOWEVER, the number of times I have seen it used on the Layout to bring in Metadata, Header, Footer or any other statically bound rendering. This WILL BYPASS Sitecore’s output caching mechanisms altogether, so every page of your site (potentially) execute every controller added in this manner.

In the code below, I have simply created a controller rendering in Sitecore (though could be any) and used its ID to display the statically bound rendering using @Html.Sitecore.Rendering().

@Html.Sitecore().Rendering(RenderingConstants.MetaData, new { Cacheable=true, Cache_VaryByData=true })

Note also the EXPLICIT caching, at the time of this post, Sitecore still has an MVC based bug that means the rendering items caching settings are ignored altogether (there is a patch and I hope it will become core)

Continue reading

Glass Mapper V4 – Redis Cache Provider

Following on from my post on the new caching functionality in Glass Mapper V4, I thought I would do something that I have been really dying to try, which is to look at using Redis to cache the models generated out of Glass. This from an architectural standpoint for me is just plain amazing :D. In this post, I will show you how you can set up a redis based cache provider for Glass Mapper V4. This post will assume you know how to set up caching on your models (shown in my previous post).

** Note – this is a proof of concept, it has not yet been tested in production, all the regular no warranty disclaimers apply.

Continue reading