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


Life Through a Lens – Using the Sitecore ContentDatabase in Glass Mapper

This post should hopefully be a short one. Just to note that in the since v4.0.3 of Glass Mapper we have added a SitecoreContentContext. This class inherits from ISitecoreContext just as the regular SitecoreContext does.

This differs from the standard SitecoreContext in that it uses Sitecore.Context.ContentDatabase instead of Sitecore.Context.Database.

ISitecoreContext sitecoreContext = new SitecoreContentContext();

Happy Mapping!!

The constructor ‘work done’ dilemma

In a recent Glass release I was working on an issue that led to Mike making a comment on how I work as a programmer. The particular issue in question was actually quite straight forward to solve – I wrote unit tests that showed the issue, wrote some sandbox tests that showed how code behaved in the underlying Sitecore library, then fixed the tests approriately. All typical of TDD. The normal thing for me though is then to write a unit test that performs this simple fix 1,000,000 times emitting the result of stopwatch timings at various points. Mike jokingly commented at the time that this was ‘typical Nat’ which, to be fair, he was right on.

In this post I will look at the effect on work done in the constructor and how it has affects your development life in the context of modern DI practice – in particular – the DI principle.

Continue reading

Life Through a Lens – Lesser known Glass Mapper features

Mapping types

[SitecoreNode] / Node() – This mapping type allows you to map to another item in Sitecore directly by the string representation of id as a guid or by its path. You would typically map this to another Glass mapped type.
[SitecoreLinked] / Linked() – This mapping type allows you to map to an IEnumerable for items that are linked to the mapped item (think navigate > links in the standard Sitecore ribbon). This (using the configuration options) can be referrers / referred to items.
[Ignore] / Ignore() – this can definitely be handy for example when injecting content from external sources into your models from controller code.

Supported types
Whilst not mapping types, Glass can indeed map to types that are not quite so commonly used.
RuleList – if you map to a rulelist (technically a [SitecoreField] mapping) then you can actually get out a usable set of conditions for use in the Sitecore rules api.
Nullable Mapping – Glass Mapper has long supported mapping to nullable .net types (e.g. int? or Nullable), this includes the majority of regular mappings with HasValue generally referring to whether the Sitecore field was empty or not.

Typed Edit Frames
“Because I am lazy” is the best and most useful introduction to a feature I have seen in a while – brought to to from this V4 Demo at around 26min 15secs. The whole video is well worth a watch, but it shows them in use. Typed edit frames though are a feature to allow the creation of edit frames based upon Glass models.

Mapping to / from external data

One of the great advantages of Glass models being detached from Sitecore (unlike most wrapping based solutions) is the ability to map data from external third party solutions. In the Glass Mapper tutorials, there is a great example of mapping Glass Mapper objects using external data.

Data transfer between environments

Another great advantage of Glass models being detached from the Sitecore item is that, using a Glass model, you can breach the master / web boundary or even environment boundary. So, for example, it would be perfectly easy to write a web service (maybe for transferring data from web to master for the purpose of saving user submitted FAQ’s for example), that would construct a Glass model on the web node, post it to the master node and save it using regular Glass code.

Model Caching
Model caching was primarily designed to allow the caching of models that are used in locations that cannot use regular Sitecore caching. This could be for example, a rendering that contains a form and would thus need to respond to postbacks etc.

Configuration Maps
Configuratioin maps are a wrapper for regular Glass fluent configuration that allows better separation from the models, it was covered in further detail in V4 – Configuration Maps

The version count disabler is a simple structure that allows Glass to behave a little more like the standard Sitecore API, in use it is really this simple

using(new VersionCountDisabler)
   var whatever = sitecoreContext.GetItem<IWhatever>(); // this code will get the item even if the version count is 0

More information on version count disabling can be found at Glass.lu – VersionCountDisabler

Typed Glass Controllers
A relatively recent addition to Glass Mapper has been the addition of a typed GlassController, this was described further in Unit Testing with GlassController

Further Reading / Watching

Glass Mapper V4 release post
Glass Mapper V4 release video

Using RequireJs to manage script dependencies based on attributes in your Sitecore Solution

A common architectural issue I hear amongst developers is how to prevent Sitecore loading all and sundry when it comes to javascript dependencies. Indeed it is often the case that front end developers don’t inform us or assume that we will use a single page type model and therefore don’t really need to worry about the number of script dependencies. The reality is that in actual fact if we included every script that a front end developer used throughout all of the scripts within the site – we would have 20 odd script tags in our markup, something you may well be keen to avoid.

As a solution to this, myself and many other developers including former colleague and Sitecore Solution Architect Richard Seal in his post Using Require to Organize your Sitecore Javascript opt to use an advanced module loader such as RequireJs. If you haven’t used it before, I recommend first reading their documentation as there are definite ways to write your javascript (and in particular jQuery) code to maximise your success with it.

Continue reading

Life Through a Lens – Unit Testing with Glass Controllers

Never let it be said that I like unit testing 😛

With the release of Glass Mapper 4.0.3 I am pleased to shout out that we have made some improvements to the unit testability of both GlassController & GlassUserControl. In addition we have also made some additional helper derivatives to make your awesome development lives even more awesome. You can find out more about the other improvements in the Glass Release Notes

In this post, I will cover some of these changes and show how you can now use GlassController in your unit tests effectively.

Continue reading

100% Code Coverage for Unit Testing is attainable (even in Sitecore)

This should hopefully be a short and probably quite marmite post.

As the unit testing debate rages on with should we / shouldn’t we? How much does it cost? How long does it take? How much of it should we test? I have continued developing my skills as a developer, lead and designer of solutions. During this time I have learned a lot about approaches to unit testing and how I could achieve better ways to test my solutions.

I do qualify what I am about to say with the following: I have been doing automated testing in some guise or other since the middle of the last decade. As such, I have been through multiple generations of the pains that developers now face in the modern era (believe me when I say, the record / replay model for early mocking frameworks was far from the ease of the current NSubstitute / Moq we have now). Also – code coverage is a metric, like all metrics – it has it’s place and I believe that it is a very worthwhile one to isolate out untested (and often potentially flawed or unknown) area’s of your codebase. As a metric, it has to have some intelligence applied the other side of it to see what it is that is untested and refactor / test accordingly.

The Common Arguments & Questions
I am going to set aside the should we (not) unit test our code. My belief is very simple – we should and we should also achieve 100% test coverage. Below are listed some of the most common ones which I will cover.

  • It has no logic – why should I test it?
  • It is too difficult to test.
  • It takes too long to write tests

Continue reading