Luke Warren Dev
Software Development Tips and Stories When I feel Like It

Your Code Sucks and Other Political Statements

There is no secret sauce or trick you haven't got around to learning to start unit testing. Your code just sucks

Your Code Sucks and Other Political Statements

OK I have got your attention. Good!

There are too many devs going around that think that unit testing was some dark art that they never learned, a waste of time or they just need some of that special sauce. Sorry folks but the reality is that unit testing is not the problem, it is your code.

With that said, do not fret! In this article I will show you a few simple tricks to get from sucky code to ... erm.. not sucky code?

Anyway, let's start with a snippet:

This code is based on a certain politician in South Africa. For non-saffas, he owed some money and needed to pay it back.

using PayBackTheMoney.Services;
using System;

namespace PayBackTheMoney
{
    public class Payer
    {
        public bool TryPayMoney(DateTime timeToPayBackTheMoney, bool canDelayProcess)
        {
            if (!canDelayProcess && DateTime.Now >= timeToPayBackTheMoney)
            {
                // Damn, have to pay
                var payer = new MoneyPayerService();
                payer.Pay(7000000M);

                // Send Thuli email
                var notifications = new NotificationService();
                notifications.Send("jacob@anc.gov.za", "thuli@madonsela.gov.za", "I pay bak moneyies.\r\n Love, Jacob");
                return true;
            }

            // "HA HA HA! "Nkandla"" HA HA HA
            return false;
        }
    }
}

Think the above code is good? It isn't. Think it is unit testable? You guessed it, it isn't!

Why? A unit test by its very definition is a method that tests a very small piece of logic in isolation. It should not rely on it's dependencies to be operational and in a certain state to be tested. Those are called integration tests.

The above is littered with concrete dependencies which makes it impossible to unit test.

Have a look again at the code. This time I have commented every issue:

using PayBackTheMoney.Services;
using System;

namespace PayBackTheMoney
{
    public class Payer
    {
        public bool TryPayMoney(DateTime timeToPayBackTheMoney, bool canDelayProcess)
        {
            // We are relying on the DateTime.Now property to return the current DateTime from the system clock
            // To test this we would need to set the clock on the PC we are using every time we want to test. What a pain!
            if (!canDelayProcess && DateTime.Now >= timeToPayBackTheMoney)
            {
                // We are using the new keyword to create an instance of our money payer service. This means that we have a concrete dependency on this class
                // Who knows what the money payer service might be dependent on to perform its "duties".
                var payer = new MoneyPayerService();
                payer.Pay(7000000M);

                // Again, as above. Newing up the NotificationService ties us to it and means that we can't test this method in isolation from its dependencies
                // Point is, we can't swap it out with a fake in our test code. We would have to make sure that an SMTP server was running!
                var notifications = new NotificationService();
                notifications.Send("jacob@anc.gov.za", "thuli@madonsela.gov.za", "I pay bak moneyies.\r\n Love, Jacob");
                return true;
            }

            return false;
        }
    }
}

As you can see, this code is using the new keyword to create services that it needs to use. This is a massive issue when it comes to unit testing because to test the Payer method you need to have both an operational NotificationService, MoneyPayerService and you would need to set your computer's clock to a new date every time you needed to test under that particular instant in time. Hear that? Those are alarm bells ringing in your ears.

Don't worry dear reader, you are not completely stuffed. We can actually very easily fix this code. Simply put, we need to make our Payer class rely on abstractions rather than concretions. This means creating interfaces to describe what each of our dependencies need to do. I like to refer to them as contracts and they will act sort of like base classes.

Interfaces are like an abstract class, except they have absolutely no implementation. Like an abstract class though, classes can inherit from them and we can then use polymorphism to handle calling the right method at the right time.

Lets now look at our fixed up class:

using DecoupledPayBackTheMoney.Contracts;
using DecoupledPayBackTheMoney.Services;
using System;

namespace DecoupledPayBackTheMoney
{
    public class Payer
    {
        private readonly IMoneyPayerService _payer;
        private readonly INotificationService _notificationService;
        private readonly IDateTimeProvider _dateTimeProvider;

        /// <summary>
        /// Here we are inverting our dependencies by letting the caller pass them in
        /// </summary>
        public Payer(
            IMoneyPayerService payer,
            INotificationService notificationService,
            IDateTimeProvider dateTimeProvider)
        {
            _payer = payer;
            _notificationService = notificationService;
            _dateTimeProvider = dateTimeProvider;
        }

        /// <summary>
        /// Lazy-man's Dependency Injection
        ///
        /// This is our public parameterless constructor. It takes care of passing in our concrete implementations.
        ///
        /// Ideally you would be using IoC framework for this like Ninject or AutoFac
        /// </summary>
        public Payer()
            : this(new MoneyPayerService(),
                  new NotificationService(),
                  new DateTimeProvider())
        {
        }

        public bool TryPayMoney(DateTime timeToPayBackTheMoney, bool canDelayProcess)
        {
            DateTime now = _dateTimeProvider.GetCurrentDateTime();
            if (!canDelayProcess && timeToPayBackTheMoney <= now)
            {
                // Damn, have to pay
                _payer.Pay(7000000M);

                // Send Thuli email
                _notificationService.Send("jacob@anc.gov.za", "thuli@madonsela.gov.za", "I pay bak moneyies.\r\n Love, Jacob");
                return true;
            }

            // "HA HA HA! "Nkandla"" HA HA HA
            return false;
        }
    }
}

Things to note:

  • We have defined interfaces for each of our dependencies.
  • Each of our services in turn inherit from these interfaces.
  • This means that our services HAVE to implement the methods defined in the interfaces.
  • Our class now relies on these abstractions rather than concretions
  • We inject our dependencies via the constructor using what is called the strategy pattern
  • Instead of needing proper versions of each of our services to test, we could now pass some fake versions of these services which do not rely on things like the system clock or a mail server
  • We can now unit test our payer class!

Note: For simplicity, we are using what is known as "poor man's dependency injection". Ideally you would rather use an inversion of control framework like Ninject or AutoFac to handle this for you so that you are even more loosely coupled.

The full source code of both the rubbish code and the better decoupled code can be found on Github. Poke around and if you have any questions leave a comment below.

Image used is from The South Africa http://www.thesouthafrican.com/jacob-zuma-announces-his-resignation-cabinet-left-jobless/


Click here to comment

Introducing the Model Builder - You Don't Need Automapper

This post is quite simple. You don't need Automapper, all you need is a model builder.

Introducing the Model Builder - You Don't Need Automapper

Now I am a big fan of "don't reinvent the wheel" but at times we as developers need to learn where to draw the line. In this article I will show you a very simple pattern that gives you more control and avoids needing to bring in yet another dependency - AutoMapper.

Disclaimer: I like and use Automapper in many of my projects and will continue to. It is a great library but sometimes you just don't need it.

Example ModelBuilder

All our model builder class does is either create a Model class from its entity/domain class equivalent OR parse a Model class back to a entity/domain class.

public class ModelBuilder
{
    public ProvinceModel Create(Province province)
    {
        Require.NotNull(province);
        Require.NotNullOrEmptyOrWhitespace(province.Name);

        return new ProvinceModel
        {
            Id = province.Id,
            Name = province.Name
        };
    }

    public Province Parse(ProvinceModel model)
    {
        Require.NotNull(model);
        Require.NotNullOrEmptyOrWhitespace(model.Name);

        return new Province
        {
            Id = model.Id,
            Name = model.Name
        };
    }
}

Wondering what that Require stuff is? Those are just some handy methods contained in the Rework Nuget Package (yes, this is a shameless plug).

ModelBuilder In Action:

I usually either inject my model builder in the constructor for the class that needs to use it, or just instantiate it right there in the constructor. The later does make it a concrete dependency rather than an abstraction but sometimes this makes sense IMO.

You could, either create a model builder for each entity-domain relationship you have or just put them all in one. You are reading this blog so I will assume that you are smart and can figure out what you prefer ;).

For completeness, here is how you actually use the thing:

    public ProvinceController(IProvinceService service)
    {
        // Init my service and create my model builder
        _service = service;
        _builder = new ModelBuilder();
    }

   public object Post(ProvinceModel model)
    {
        Province province = _builder.Parse(model);
        _provinceService.Create(province); // My "service" is creating the province in the DB
        return _builder.Create(province);
    }

Click here to comment

New Version of Rework Available

My helper is slowly becoming something useful

New Version of Rework Available

Happy to make a quick announcement that Rework is slowly getting useful!

A new version is out and features some more handy string functions for truncating strings. The library is still very light but does help eradicate some silly boilerplate code

Check it out on Nuget and Github or simple install it with the Nuget Package Manager command Install-Package Rework


Click here to comment

My First Nuget Package: Rework

I am so tired of rewriting the same code over and over and over again

My First Nuget Package: Rework

So I have been wanting to do this for a while but finally got around to creating a reusable C# library.  

The library contains all the sort of helper functions that you tend to re-write, redo or "Rework". It is currently quite light but is fully unit tested and highly reliable. I am using AppVeyor for Continuous Integration and Deployment to Nuget.

I am hoping to do a video at some point on just how easy it is to setup a project in AppVeyor. For more info on the project, it's features and how to use it. Simple head over to Github.

If you like the library and want to add to it, feel free to contact me or put in a pull request.


Click here to comment

How to configure the Hangfire Dashboard in an ASP.NET App

Hangfire is an awesome little library to aid in the scheduling of recurring or deferred "jobs".

How to configure the Hangfire Dashboard in an ASP.NET App

Hangfire is an awesome little library to aid in the scheduling of recurring or deferred "jobs".

It comes with a handy dashboard that, when configured, allows you to easily monitor and take actions on your jobs.

The problem I have come across on StackOverflow and other sites is that many people battle to get the dashboard setup, so I thought that I would document here how it is done.

First we need to create an authorization filter

This will be used later to make sure that only authenticated and authorised users can access the dashboard.

This means making sure that users are both logged in and in the admin role before they can view the Hangfire dashboard.

using MyApp.Common;
using Hangfire.Dashboard;
using Microsoft.Owin;
using System.Collections.Generic;

namespace MyApp.Dashboard.Schedules
{
   public class HangfireAuthorizationFilter : IAuthorizationFilter
   {
          public HangfireAuthorizationFilter()
          {
          }

          public bool Authorize(IDictionary<string, object> owinEnvironment)
          {
             // Only admin users can access the dashboard
             var user = new OwinContext(owinEnvironment).Authentication.User;
             return user.Identity.IsAuthenticated &amp;&amp; user.IsInRole(RoleKeys.Admin);
          }
      }
}

All you need to do really is implement the IAuthorizationFilter interface and you are away.

Next, we need to configure our app to use the Hangfire dashboard

I usually just create a static method that sets up the dashboard and adds whatever jobs I need run.

We are using the authorization filter created previously.

public static class ScheduleConfig
{
    public static void ConfigureSchedules(IAppBuilder app)
    {
        // Configure Dashboard
        GlobalConfiguration.Configuration.UseSqlServerStorage("DefaultConnection");
        // I like to use "/jobs" as my endpoint
        // but your could change that to whatever you like
        app.UseHangfireDashboard("/jobs", new DashboardOptions
        {
            AuthorizationFilters = new[] { new HangfireAuthorizationFilter() }
        });
        app.UseHangfireServer();

        // Add jobs
        //...
    }
}

All we need to do now is call our method from within Startup.cs

public partial class Startup
{
    public void Configuration(IAppBuilder app)
    {
        // Other startup config
        //...

        // Call our method to configure hangfire.
        ScheduleConfig.ConfigureSchedules(app);
    }
}

Now (once logged in as admin) you will be able to navigate to the dashboard via http://yourappdomain.com/jobs


Click here to comment

How to get all Content by Document Type in Umbraco

This is probably going to be my shortest post yet. After having messed around with Umbraco for the last few weeks I thought that I would share some code!

How to get all Content by Document Type in Umbraco

OK, straight to it

Please note that on large sites you probably want to cache the results of the method to avoid a performance hit.

public static IEnumerable<IPublishedContent> GetAllNodesByType(IPublishedContent home, string docTypeAlias)
    {
        var foundNodes = new List<IPublishedContent>();
        foreach (var content in home.Children)
        {
            if (content.DocumentTypeAlias == docTypeAlias)
                foundNodes.Add(content);

            // Check recursive
            if (content.Children.Count() > 0)
                foundNodes.AddRange(GetAllNodesByType(content, docTypeAlias));
        }
        return foundNodes;
    }

Click here to comment

Scheduled Job Runner in an ASP.NET MVC App

simple apps do not need the feature bloat

Scheduled Job Runner in an ASP.NET MVC App

I have finally had the chance to build a few apps in vanilla ASP.NET MVC recently. While we still prefer DNN for many use cases, simple apps do not need the feature bloat you get when building on top of DNN. Sometimes in this vanilla context you find yourself missing things that you get for free in DNN.

Scheduled jobs

DNN provides an extremely easy and configurable way to run a task or "job" on a schedule. I needed something similar in an MVC app.

Turns out that it is not as hard as it seems when you break it down.

Find a job runner

First we needed something to actually handle running our recurring jobs. While you could write something yourself, that would be a waste of time considering it is a solved problem. I found a few nifty little libraries and decided that the best one to use would be Hangfire.

Hangfire allows you to easily run code on a schedule as well as monitor them via a dashboard (Hangfire has many many more features).

Discover our jobs

Now you could just use hangfire to run whatever code you want on a schedule off the bat but I wanted my implementation to require no code changes when a new job is needed to be run. You should just be able to write you code and have it run itself.

If I want to create a new job, it would just need to adhere to a contract that I defined. This simply meant creating a interface to act as my "contract"

My Interface:

```

public interface IScheduledJob {

string Frequency { get; }

void DoWork(); }

```

Now that I had a contract, I needed a way to discover all the classes that inherited  from my interface - ie all the "jobs" to register on app startup.

The following method is called in the Startup.Configure method and essentially just finds all the jobs and adds them to a recurring job schedule:

```

private void ConfigureSchedules(IAppBuilder app) { // Configure Dashboard GlobalConfiguration.Configuration.UseSqlServerStorage("DefaultConnection"); app.UseHangfireDashboard("/jobs", new DashboardOptions { AuthorizationFilters = new[] { new HangfireAuthorizationFilter() } }); app.UseHangfireServer();

// Get all types that implement the scheduler interface var jobs = AppDomain.CurrentDomain.GetAssemblies() .SelectMany(s => s.GetTypes()) .Where(p => typeof(IScheduledJob).IsAssignableFrom(p) && !p.IsInterface); foreach (var jobType in jobs) { // Create instance of job IScheduledJob job = (IScheduledJob)Activator.CreateInstance(jobType); // Add job to schedule RecurringJob.AddOrUpdate(() => job.DoWork(), job.Frequency); } }

```

*Note, for more information on the dashboard see the Hangfire docs *

Create a job

OK, now we are cooking on gas. We just need to create a class that inherits from our interface and it will automatically be added to the schedule

An example job:

```

public class TestSchedule : IScheduledJob
{
    public string Frequency
    {
        get
        {
            return Cron.Minutely();
        }
    }

    public void DoWork()
    {
        Debug.WriteLine($"Test Job Ran: {DateTime.Now}");
    }
}

```

Note that we use Hangfire's built in Cron class to define the frequency of our job. These methods simple return a string.

Happy scheduled-jobbing!


Click here to comment