Breaking Up With Integration Tests: Switch To Collab & Contract Tests

According to J. B. Rainsberger, integration tests are a scam because of combinatorial complexity and a tendency to create MORE bugs. Complicated tests involving multiple units beget poor design, whereas tiny, isolated tests, are resilient and put pressure on our designs to make them better.

Four days ago, I achieved 100% unit test coverage. Today, I finished adding over 300 lines of code of functional UI tests for blogthedata.com. After watching Rainsberger's talk, maybe I should drop them?

Integration tests is any test where the success or failure depends on many bits of interesting behavior at once…where when it fails, I cannot point to where the problem is.

J.B Rainsberger

Rainsberger advocates for hexagonal architecture where different parts of the system are checked in isolation. Instead of integration tests, you write collaboration and contract tests to validate functions interact with interfaces correctly.

Collaborations Tests

• Do I ask the server the right questions?
• Can I handle all the answers the server gives me?

Contract Tests

• What questions can I answer?
• Do I really try to answer that way? 

Collaboration tests are about whether senders and receivers can understand each other's questions and answers. Contract tests are about whether the type and content of each question and answer conform to an established standard. 

What's fantastic about this approach is that the client and server are tested independently. By using stubs and mocks, you can turn what would otherwise be an integration test into a unit test!

As I develop blogthedata.com, I will migrate away from integration toward collaboration and contract.