Arguments around Solitary versus Sociable Unit Testing

First some notions on the test pyramid from Martin Fowler, and also on concept of solitary and social unit tests.

Solitary unit test can be defined as a test class where the one and only concrete service is the service under test (all other dependencies, except for data/value types are mocked)

A social (sociable) unit test is instead one which uses concrete service dependencies to test the class currently under test. Also called component test.

I believe as usual there shouldn’t be a strict rule around that, but is worth noting some differences, in order for us to sort the best approach based on the context.


2. less need for mocks/stubs (dependencies are «sociable» so they are concretely injected) – except integration layers (dB, time, network, etc)

3. ease of refactoring (less tests to change) – though if high level coverage is not complete, can be easy to break something without notice.

4. all dependent injected services/classes (being concrete) needs to be initialized with their own dependencies as well (not ultra nice)

5. mostly black boxed (even though the developer still knows the inner code underlying it, so it’s sort of a trick – it’s not a separate team like E2E testing)

6. usually slower (though can be fast enough) and might be not cheap neither to write, to throw away


2. easier maintainability due to the previous reason (also focus on test code is better with smaller files, smaller classes)

3. simpler code enabler – small unit test enable/enforce small code units/components, resulting in decreasing the complexity of running software, whereas component unit test do not enforce that.

4. Forces developer to think about logic paths and boolean expressions (which can be counter intuitive some times)

5. mocks reduction – smaller classes have less dependencies and thus need less mocks to be tested

6. initialization (mock setup) is needed only for code which is really hit by the test flow (this can be partially achieved also in social testing passing null where possible)

7. the object/service under test is really and only the one tested (and not other objects), making impossible for other components to have «side/unexpected effects» on the object under test behavior

8. fastest and cheapest to write, also cheap to throw away when not needed (just one class and no dependencies on others)

Let me know if you see other differences , pros and cons, I’d be happy to amend.

Cheers and have a covered day! : )