###### tags: `testing` `unittest` `integrationtest`

# Unit tests vs Integration tests (by [Jay Bazuzi](https://twitter.com/jaybazuzi))

https://twitter.com/jaybazuzi/status/1450474664871043084

"What ratio of **unit tests** to **integration tests** we want to strive for?" 80:20 was proposed.

I like a different framing:
* If code might be written incorrectly, use a **unit test**.
* If code might "correctly" encode an incorrect understanding of a dependency, use an **integration test**.

Use **integration tests** to detect integration problems. If they detect local problems, that shoulda been caught by a **unit test**.

Sometimes this is difficult, if the code that talks to a dependency has a local mistake. In that case, refactor to make it testable in isolation.

In this way, my integration code is 100% tested by integration tests, and my non-integration code is 100% tested by unit tests.

(My integration test code is also partially tested by unit tests, but that's a separate discussion.)

Examples of **integration mistakes**:
* API expects JSON shaped this way, but I thought it should be shaped that way.
* Windows program reads / writes files ignoring case; fails when I port to Linux.
* Another team writes a component I will depend on; we interpret the design differently.

Examples of **local (non-integration) mistakes**:
* I forget the operator precedence rules in my language.
* A function I write occasionally passes null to a function I write that never expects null.
* A format string where some parameters are wrong.