Background Image
Table of Contents Table of Contents
Previous Page  426 / 478 Next Page
Information
Show Menu
Previous Page 426 / 478 Next Page
Page Background

system could be an external system, like a database, but it could also be another

function which we don’t control. In either case, if breaking the system makes our

test fail, our test is not properly isolated, it is not a “pure” unit test. That’s not

necessarily a bad thing, but it may mean the test is doing two jobs at once.

Integration tests

An integration test checks that the code you control is integrated correctly with

some external system which you don’t control.

Integration

tests are typically also

integrated

tests.

System tests

If an integration test checks the integration with one external system, a system test

checks the integration of multiple systems in your application—for example, check‐

ing that we’ve wired up our database, static files, and server config together in such

a way that they all work.

Functional tests and acceptance tests

An acceptance test is meant to test that our system works from the point of view of

the user (“would the user accept this behaviour?”). It’s hard to write an acceptance

test that’s not a full-stack, end-to-end test. We’ve been using our functional tests to

play the role of both acceptance tests and system tests.

If you’ll forgive me the pretentious philosophical terminology, I’m going to follow a

Hegelian dialectical structure:

• The Thesis: the case for “pure” unit tests that are fast.

• The Antithesis: some of the risks associated with a (naive) pure unit testing

approach.

• The Synthesis: a discussion of best practices like “Ports and Adapters” or “Func‐

tional Core, Imperative Shell”, and of just what it is that we want from our tests,

anyway.

Thesis: Unit Tests Are Superfast and Good Besides That

One of the things you often hear about unit tests is that they’re much faster. I don’t think

that’s actually the primary benefit of unit tests, but it’s worth exploring the theme of

speed.

Faster Tests Mean Faster Development

Other things being equal, the faster your unit tests run, the better. To a lesser extent, the

faster

all

your tests run, the better.

398

|

Chapter 22: Fast Tests, Slow Tests, and Hot Lava