Andy Butland

Found a use case for a feature of the .NET mocking framework Moq that may not be that well known, and was new to me at least. I had a method under test that - via a number of overloaded extension methods - called an underlying method in the Umbraco CMS. The details aren't really important, but specifically it was the method GetImageUrl on IImageUrlGenerator that I was mocking to return a known output. I was then testing how my method used that result it in it's processing. I could see the method failing when I had a setup like this: But passed with this: So clearly we weren't passing in the Height parameter that I was expecting. One way to solve this would be to get the Umbraco code locally and step into it, but I found another way that I read about on this closed issue for the Moq library. It provides a means of capturing the parameters passed to a mocked method, and then establishing what they are via a breakpoint or logging. That revealed that so...

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 ...

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...

Short post to follow, generalising something I've just done in an active project that seems to have general relevance. I had an interface and class like this, that wasn't easy to put under a unit test. interface ISomething { string GetValue(); string GetComplicatedConvertedValue(); } class MySomething : ISomething { string GetValue() { // Get value from something that's a simple one-liner call but not easy to mock or stub (in my case, Sitecore settings) ... } string GetComplicatedConvertedValue() { var rawValue = GetValue(); // Do some processing on the raw value that ideally we'd like under unit test, and return it ... } } One answer I realised is that, as the main value for testing this class is in the second method - retrieving the raw value is hard to test, but little value as it's a one liner into platform functionality - I can just remove that from the interface, and...

A quick recap A little while back now I spent a bit of time investigating how one might go about unit testing Umbraco surface controllers . With the help of information posted by some others that had similarly looked into it I found there was a method that worked, but it wasn't ideal for a number of reasons. Firstly there was a need to utilise an Umbraco test helpers dll , that contained implementations of various base classes that could be used to support testing. No great hardship to use that but it did mean you had to compile the source to get it and it led to some other restrictions on your tests. One of those being you had to use NUnit . Again, a perfectly decent test runner but if you generally used MSTest or something else you had to make a switch. And lastly in order to create various surface controller dependencies, you had to use some rather impenetrable looking reflection code to get around the fact that certain classes and methods were marked as internal rat...

Previous posts in this series Rich Domain Models and Entity Framework. A CQRS Implementation with ASP.Net MVC and Entity Framework . Introduction to the series . Introduction In my previous post I discussed steps I've been taking with recent application to move more logic and behaviour into a richer domain model. This has a number of advantages, a significant one being ease of testing of this behaviour. As this is coded as methods on a standalone model class, it's very easy to test due to it's lack of dependencies. Nothing needs to be mocked or stubbed; an instance can just be instantiated in the test method and the appropriate methods called and results asserted. Given the CQRS style approach I've taken elsewhere in the applications, MVC controllers are fairly light and have less value for testing. The main part of the application where logic lies is in the individual query and command handlers. These have a tight dependency on Entity Framework thoug...

With the release of Umbraco 7.3, this has got a whole lot simpler - see my more recent post discussing this topic In the previous post I looked at testing Umbraco surface controllers, using a technique that basically avoided the issue by extracting the non-Umbraco related logic for test into a separate class, and testing that. Another option is to test the controller as is, using the base test classes provided by the Umbraco core team. My starting point for working with these was a blog post by Jorge Lusar where he details much of the process for working with these. He used Umbraco 6.1.5, and I found things had changed a little in 7.1.0 (latest at time of writing), as well as needing some additional work to handle the controller methods I was looking to test. As Jorge notes, the first things is to get the test classes. They aren't currently available as a separate download as far as I'm aware, so instead I've pulled down and built the latest source code, and t...

When coming to work with Umbraco as an MVC developer one feature that is immediately familiar and comfortable to work with is surface controllers . Unfortunately, unlike standard MVC controllers, they aren't straightforward to test. In this blog post I'm going to look to start from scratch, uncover the issues and see what options we have to get around this. Failing test attempt Starting with a simple example taken from the Umbraco documentation , this surface controller action very simply handles a form post. The view model: public class CommentViewModel { [Required] public string Name { get; set; } [Required] public string Email { get; set; } [Required] [Display(Name = "Enter a comment")] public string Comment { get; set; } } The view and the form in a partial: @if (TempData["CustomMessage"] != null) { @TempData["CustomMessage"].ToString() } @Html.Partial("_CommentForm", new SurfaceCont...

Update: with more recent versions of Umbraco, there is a way introduced to me by Lars-Erik and documented in his blog post here that allows for testing IPublished content as attempted in this now fairly old post, without the user of MS Fakes. Given the the MS Fakes product still requires the Ultimate version of VS.Net I'd recommend using the technique he describes. I've recently been working on a package for Umbraco called Umbraco Mapper . It's intention is to support development of MVC based Umbraco applications by providing a simple means of mapping Umbraco content to custom view models. You can read more about it on the GitHub page . For a few weeks now I've on and off tackled a problem I've found with unit testing part of the functionality. Umbraco content is represented in the front-end of the application by an interface IPublishedContent . What I'm looking to do is to create an instance of IPublishedContent with some known properties, map it to a...

Unit testing Umbraco surface controllers isn't straightforward, due to issues with mocking or faking dependencies. There has been some discussion about it and there are some workarounds regarding using certain test base classes. But in general it's not an easy thing to do, at least at the moment. Another approach (or workaround) for this is to move the thing you are trying to test outside of the controller and into another class - that itself depends only on standard ASP.Net MVC. Test that instead, leaving your controller so simple that in itself there remains little value in testing it directly. As an example, I had this to test: [HttpPost] [ValidateAntiForgeryToken] public ActionResult SignUp(NewsletterSignUpModel model) { if (ModelState.IsValid) { // Model valid so sign-up email address var result = _newsletterSignUpService.SignUp(model.Email, model.FirstName, model.LastName); ...