When learning to write unit tests nowadays it’s highly likely that you’ll be taught about using test doubles (or ‘mocking’ if using slang). However, I think it’s rare you’ll be taught or even hear about the notion of sociable unit testing, a term coined by Jay Fields in his book Working Effectively with Unit Tests.

I first heard about this concept from Martin Fowler’s website which is filled with nice snippets of wisdom. I’m not going to re-explain the difference between solitary vs sociable but it summarises into whether you should isolate your class completely using test doubles (solitary) or use the concrete dependencies themselves (sociable).

Sociable vs Integration

But if you’re using concrete dependencies then surely that’s integration testing and not unit testing?

The main difference between a sociable unit test and an integration test is the goal in what we are testing. A sociable unit test assumes the other dependencies work with the goal of testing a single unit. An integration test meanwhile aims to test several units successfully work together. At a low level, this can make sociable tests and integration tests look very similar and hence the confusion between them.

Integration testing is useful when two or more separate modules have been developed/tested independently and now need to be tested together. The assertions of an integration test are likely (and should) be aimed at checking the modules cooperate rather than the correctness of each module - that would be the job of the unit tests. For example, I would not expect a set of integration tests to test each and every case. For a real-world example, I find integration tests going from the API all the way to a dummy database through all the layers a good test when using EntityFramework. With a single unit test, it’s easy to test something that uses EntityFramework with a dummy database. But, when you combine the different units, you can then end up with these DuplicateKeyExceptions because some other part of the system has loaded some of the data you also want to load already. I find a set of ‘happy path’ cases that test the minimum and essential functionality I want in a ‘worst case’ situation (minus hardware completely failing) provides me with a lot of confidence to release often.

On the other hand, I would expect a sociable unit test to cover all the cases for the system under test. If you’re developing code inside-out (more on that below), you won’t need to test any actual dependencies as they already have tests associated with them. This does mean your collection of unit tests (directly and indirectly) test the same parts of the code multiple times in the test suite. Some people have an issue with this as it can make working out what made a test fail more difficult. If you’re doing TDD, where you’re frequently making small changes and then running the tests each time, it’s almost always self-evident what caused the tests to fail. For developers that like to make a bunch of changes and then run the unit tests at the end, seeing loads of red is indeed a bad sign and does require further investigation as it’s just not obvious what caused the test failures.

In an environment where most developers are not using TDD, there is an argument not to do sociable unit testing and instead use mocks (test doubles) for the reasons I’ve explained above.

Inside-Out (Chicago Style)

It’s worth noting that in order to do sociable unit testing while doing TDD it does force you to work in an inside-out style rather than outside-in.

If I was building a web API for example I would start from the domain, towards my application layer and then I’d implement the web API last. This has its advantages and disadvantages but I’ll save that for another blog post. Going inside-out means you can use the implementations you’ve just written in the layers above.

The more common approach to unit testing is to go outside-in, with a web API for example you’d start implementing the controller and mock any dependencies you think you might need and work your way down the layers one by one until you’re done mocking the dependencies each time.

What is a unit?

The other debate that sometimes comes up between unit testing and integration testing is ‘what is a unit’?

‘Unit’ isn’t well defined, it completely depends on who you ask. I’ve known one company that treats every public method as a unit with a corresponding test class for each method. The most common answer is that a class is a unit. I like to think of ‘unit’ as a sliding scale, sometimes it’s a single class but other times it’s a group of classes. How do I decide how big or small my unit is going to be? Value.

Focusing on the value tests provide you as a developer is far more important than worrying about whether you’ve written a unit test or an integration test. Understanding the value that each type of test brings comes with experience and that’s why it’s important to experiment - don’t get stuck writing tests using the same old strategy you’ve always used.