Andy Butland

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

Async and await are two keywords that have been available in the C# for a while now. And so whilst probably a bit late to the party thought would share how I've used them for a recent feature, in case they are also new to others. They allow you to write async code much more easily than was previously possible, which should allow applications to scale better - particularly when there's a need to call out to slow running processes (e.g. external web services), or really anything that is "IO bound" (like a database call. So for example you could speed up a web request that requires two calls to two long running processes by running them in parallel on different threads and then waiting for both to return. If they both take 1 second your result can return in 1 second instead of 2. But even with just one long running process in the request, it's still useful, as whilst that process is running the thread serving the request is no longer blocked, and can return ...