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.
Here is something that I have found all too often in my career working with a multitude of CMS systems, and it is this :-
Sitecore is not a product that you can build for a customer and then forget about, customers to get the best from their solutions should be hand held, communicated with, and as developers / vendors – this provides long term work opportunity. It is all to often that (especially in the Digital Media Agency environments) I find Developers blindly following a spec (often written by someone who does not know the framework) and not considering the bigger / long term picture. In my experience, this often leads to a lot of work later that would have been next to no work during the original implementation.
In my post on The parallels between single language and multi-language developments I covered just such a question. It eludes to statements you will often here from clients which could include (but far from limited to), things like:
- We will only ever have an English site
- We will only ever run one site on our Sitecore solution
- We will always use workflow
Our journey in development should always be governed by a mix of knowledge gained through a variety of mediums, the fact you are even reading this post suggests you are eager to learn more about the product(s) you work with. This added to your own experience and the shared experience of your wider team should lead to you making ever increasingly better decisions with each solution you build. So my responses (based on my own experience and in my head) to this are usually something along the lines of:
- Really…..? Your ‘massive’ brand that you have sold us on since the pitching process has no plans to EVER consider beyond the English market?
- Ok – so your CEO is going to build your brand and sit on their ass and watch the money fly in without thinking – ‘hey we could make some more by..’
- You really haven’t thought about basics like – every image, every tiny translation change… well just… EVERY CHANGE! It’s great that some clients have vast content entry teams with the resources to achieve this. Many clients though will end up with an army wanting ammo and a single guy with the keys to the ammo store (chips down – that guy is gonna get a beating).
The above are all examples of me using my experience / knowledge to question whether the decisions that have been made (often in the developers absence and often by sales / accounts folk) will actually hold up.