More often than not, I want to assert that my dependency has been called with a parameter that matches more than one condition.

Let’s say we have a method that calls ICustomerService.Add method.
We want to assert the Add method was called with a Customer that matches a few conditions.

The way we’d typically achieve this is by doing something like this:

This will work. And it will indeed assert that the AddCustomer method was called with a Customer object, with those properties set to the corresponding values.

The problem lies if one of those properties doesn’t match.
We get a failed test. But no idication of which property it’s failed on.

What I like to do instead, is follow this pattern:

So, here, we’re basically saying when Add is called, with any Customer object, Invoke the anonymous function, that takes the Customer argument, and stores it in addedCustomer.

We can then individually assert on each property.

I created an issue on GitHub which addresses this, with a view to finding a more ‘inline’ solution

When testing a simple express app / api I like to use supertest.

This can feel like integration testing, and to an extent it is.
But we can stub things out with sinon, and tidy up our tests.

Let’s look at an example.

Suppose we have a simple API with the following router:

To run the app, we have a separate server.js:

This makes loading our app much easier in our supertest tests, as we’ll see later on.

Ok, nothing complex going on here –
We can see we have some authentication middleware on all of our routes:

This is some very basic authentication, for the purposes of our demo:

Ok, all is good, our app runs, and if we don’t supply an authentication token in the header, we’re returned a 401, otherwise, we’re presented with ‘Hello’

Our tests currently look like this:
(see the full test at this version here)

These all pass


The testing for with / without authentication header set stuff bothers me;
For a start, it’s a cross cutting concern – it shouldn’t be tested like this.
Plus – we’re integration testing our authentication middleware.
What happens if/when we make this more complex?

Much better would be to stub this out.

So, by changing our test slightly as follows:

We can create a stub of our ensureAuthenticated middleware.

Important here, is to note the removal of the “with authentication header set” tests… we don’t need them anymore! That’s taken care of by

Hope this helps!

I’ve added the full code on GitHub: GitHub

.net project unit test naming

Just wanted to do a quick post on unit test method naming, in particular with .net projects;

Most test suites I come across are title cased:

This annoys me. I find long method names hard to read, and easy to miss detail


is not a readable as:

Recently, I was writing a module that took a callback, and needed to write a test, asserting on an exception.

Here’s how to do it:

Assuming our module looks something like this:

While running my tests, I noticed that if I ran my test suite all together, some would fail, giving the exception:

API restriction: The assembly has already loaded from a different location

This issue was happening both in ReSharper test runner, and using the NUnit test runner

Debugging, the exception was being thrown on my SetUp methods like:

I posted about this on StackOverflow, and tweeted contributors of the FakeItEasy project.

At the time of writing, there is an immediate workaround:

Run tests in parallel.

To do this for the ReSharper test runner, do the following:

Options -> Unit Testing -> Run up to x assemblies in parallel.
(Set to anything greater than 1)

How to run tests in parallel with resharper


An issue has been created on GitHub for this: