Andy Butland

Cross-posting an article summarising some recent blog posts from here on making practical decisions around unit testing , written for Zone's blog.

I think this will be the final post in this unplanned series on "Practical Decisions on Testing". Previously posts have covered: Considering a Unit Code coverage metrics Trading off value with difficulty In this post I wanted to consider the topic of test driven development (TDD). It's a technique that tends to divide developers into two camps, those that swear by it, and those that don't touch it (even if they are on board with unit testing itself). Over the course of my career I've used it on occasion, and found some value, but on balance find I fall mostly into the "tests after" camp, and the method of using tests to drive the design of the code isn't something that's really become part of my programming workflow. In particular, going the full TDD approach where you write code that doesn't initially even compile isn't something I've found grabs me, perhaps due to my background in statically typed languages, primarily C

Without intending to when I started, I've three posts on a topic now, which I think constitutes a series on "Practical Decisions on Testing". Previously posts have covered: Trading off value with difficulty Code coverage metrics As with the above two posts, the intention I've primarily got is to put down in words some discussions I've had at various times, for a reference and as something to point to. In this post I want to discuss what we consider as "the unit" when it comes to unit testing. For many developers, it's the class, and the mark of good coverage is to ensure that all public methods - and via them, the private ones - are covered by tests. In doing so, there will certainly be a well tested code base. There can be a downside discovered in this though, in that it serves as a deterrent for refactoring at the inter-class level. For example, a decision to split the responsibilities of a class into two to better meet the single re

Another short reference post on the topic of unit testing, in the spirit of saving your keystrokes , based on a conversation I've had a couple of times concerning unit test code coverage. We're using Sonarqube on a current project, which, amongst other things, will review C# code and determine the percentage covered by unit tests. We're currently running at around 80%, which to me seems a fairly healthy metric. It's not the be all and end all of course in that a high percentage of test coverage doesn't completely diagnose a healthy code base, but, all things being equal, it's a good sign. The question then comes - why not 100%? Not in the naive sense though - there's clearly areas of the code, property getters and setters being the classic example, that you could unit test, but wouldn't get much if any value in doing so, and hence the effort is unlikely to be worthwhile. Rather in the sense that if there are areas that's aren't going

I've recently been investigating ML.NET , learning by doing implementing a sample project to try to predict a country's "happiness score" based on various geographic and demographic factors. Cross-posting the resulting blog post shared on Zone's digital output.

I've published two new releases of the Umbraco Personalisation Groups package, providing personalisation features for websites built on Umbraco, supporting Umbraco 7 and 8. They are available on Our for download or can be installed via NuGet (though it's best to go the package route for a first install, to help with setup of some necessary document and data types). With Umbraco 8, a concept of segments and variants has been introduced, that will likely be able to be used for providing similar features. The initial release though only deals with language variants for multi-lingual sites, so, at least for now, think the package will still have some value. Release Details There are two new versions of the package: Version 1.0 - targeting Umbraco 7 Version 2.0 - targeting Umbraco 8 Umbraco 7 (Personalisation Groups 1.0) Release This provides almost the same functionality as the most recent 0.3.6 release. I have bumped the major version partly due to it being

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

Cross-posting Reviving ZoneBot: rebuilding using V4 of Microsoft Bot Framework

Like most development teams working on modern, Sitecore projects of reasonable complexity, at the agency where I work we've followed the Helix design principles and conventions for Sitecore development in structuring the solution. This means we have 3 groups of projects: Foundation - at the lowest level, these projects may depend on each other but don't depend on any in the higher levels. Modules in the Foundation layer are business-logic specific extensions on the technology frameworks used in the implementation - e.g. Sitecore itself - or shared functionality between feature modules that is abstracted out. Feature - these are projects in the middle layer, which may depend on Foundation projects but not on any in the higher Project level and, importantly, not on each other. Projects here should map to a business domain concept or feature. We've extended the feature level in a small way by introducing the concept of sub-features. For example, for a data import