May 28, 2016

Architecting Microservices in .NET at DDD Sydney, 2016

I've just finished delivering my Microservices talk at DDD Sydney and promised the folks a few links so they could look back on things and get some ideas for their own projects.

Before that, a big thanks to everyone in the audience who came along and asked questions. We covered a lot of ground in a short amount of time!

Remember that the code in the GitHub repo is for inspiration, not duplication and there is some incomplete code in the repo (sorry about that).  The slides have plenty of bullet points and notes so you can come back and look at things after the fact, and use it as a reference.

Here's the links:
GitHub repo:

May 17, 2016

Some upcoming events

(Wow, it's been a while since I posted - sorry, all!)

In case you aren't aware, there's a few developer events coming up that I'm involved in that I thought you might like to know about.

DDD Sydney - May 28th

I'll be talking about Architecting Microservices in .NET.  Should be fun :-)

Agile 2016 - July 25th -29th

I'm co-chairing the Dev Practices and Craftsmanship track this year. I'm pretty excited about the content and we've got some great speakers and amazing topics if you can make it.

NDC Sydney - Aug 1st - 5th

I'll be jumping off the plane from Atlanta and doing 2 talks

The first is a variation of the Microservices talk I'm doing at DDD Sydney, and the second is a talk on the revamped build system in VSTS and integrating with SonarQube for automated metrics and technical debt monitoring.

There's still tickets available to all 3 events, so I'd encourage you to have a look through the content at all of them and see what takes your fancy. There's always something new to learn in this field, and I'd love to see you there!

Jul 14, 2015

Stop Using Assert.Throws in Your BDD Unit Tests

I’m sure we’ve all seen the Assert.Throws assertion in test code by now, but just in case you haven’t, here's a simple example:
public void InsertTestNameHere()
    var input = "a string";
    Assert.Throws<FormatException>(() => int.Parse(input));
If we consider this from an Arrange-Act-Assert (AAA) perspective it’s pretty easy to see that the Act and Assert logic are in a single line. It’s a very common pattern. It works, it works well, and the readability is fine, but if we start using a BDD approach to our unit testing (e.g. with SpecFlow) or we want to explicitly keep the Arrange, Act and Assert sections of our test code separated then Assert.Throws gets in the way.
To fix this we need a way of catching the exception and treating it like a normal object. In NUnit, the Assert.Catch method is for just this purpose. Here’s the adjusted code (using NUnit)
public void InsertTestNameHere()
    var input = "a string";
    var exception = Assert.Catch(() => int.Parse(input));
In this case we’re catching any exception that int.Parse might throw. If we were more explicit and used Assert.Catch<FormatException>(), NUnit’s behaviour becomes much the same as Assert.Throws, and the test fails immediately if the expected exception isn’t detected. This isn't a behaviour we want, which is why we're using the generalised catch method. Now, since we have our exception in a variable, we can check if it’s the one we expected.
Oh, I forgot to mention it, but if no exception is thrown, Assert.Catch() fails the test immediately. It is an assertion after all. I’m sort of OK with this… but not really, as we’re still mixing assertions and actions on the same line and haven't resolved my original complaint.
For this reason I prefer XUnit’s approach.
public void InsertTestNameHere()
    var input = "a string";
    var exception = Record.Exception(() => int.Parse(input));
The Record.Exception() method won't fail the test, regardless of what happens in the method. Unlike the NUnit approach, it merely records any exception arising from the call or returns null if no exception was thrown. Personally, I feel this approach is a better way to write tests around exceptions while still remaining consistent with the AAA approach. It also works well when using a BDD testing framework that separates the given/when/then step implementations as you can pass the result of the “when” method to the “then” methods with ease.