Andy Butland

Today I've published two new versions of the Umbraco Mapper package , a package that supports the use of view models, by mapping Umbraco content to custom view model classes (original thinking was Automapper for Umbraco I guess). They are available on our.umbraco.org for download or can be installed via NuGet . I was surprised to see that it's been over 5 years since this package was originally built by myself and some colleagues at Zone - a long time in technology. We're still making use of it though, and as I had some popular demand - well, two people(!) - for a version compatible with the latest Umbraco release, thought it would be good to prepare one. I've taken an approach of restructuring the solution such that there's a common project, containing non-Umbraco dependent core set of functionality, and then created two Visual Studio projects within the solution, one referencing the Umbraco 7 binaries and one the Umbraco 8 ones. That way, I can suppor

Recently I had reason to condense an approach to decisions around the value versus the effort of testing - specifically unit testing, but likely it applies at higher levels - and came up with the following diagram that I think illustrates it quite well. On it we see two axis: one being the value of the tests and the being how difficult it is to write the tests. We can consider here that code that's complex, expresses business logic etc. is something that's going to be high value, but very trivial code down to the level of property getters and setters likely won't add much, if any. Code that's easy to test will have little or no dependencies that may require mocking or stubbing. Sometimes though code can be is particularly difficult to test, often when tied to platform components that prove troublesome or even impossible to treat in this way. The graph then breaks down into four quadrants: Bottom right - easy to test and high value . This is the sweet-spot wh