When it comes to modelling data using Glass Mapper, we as developers can often find there is too much choice. In this post I will look at some of the common scenarios & considerations we as developers are likely to face and how I choose to approach mapping with Glass Mapper on the Sitecore platform.
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
A slightly strange title, but let me explain. First of all – it’s possibly self evident, but for those who don’t see it – developers in so many industries are treated similar to mushrooms – keep them sustained in a dark room and they will produce useful material. On the other hand – we have marketers / designers / project managers. The former two of which are (and rightly so in many instances) considered to be the driving forces in their field and thus are exposed to the sun (the clients / world) by virtue of glass walls & ceilings.
I have for many many years been both a developer and a social person. I enjoy interacting with clients / fellow developers & others – be them from media agencies or ‘end’ clients (ie: Sitecore Customers) and I have found distinct differences between the way different organisations interact with their own developers and (from a personal point of view) what I consider to be a disparity in how productive the developers can be directly linked to how close they are to the problem.
In this post I will explore why developers (mushrooms) should be allowed out to see the wider picture (greenhouse) more regularly.