47 lines
2.1 KiB
ReStructuredText
47 lines
2.1 KiB
ReStructuredText
|
.. _test-anatomy:
|
||
|
|
||
|
Anatomy of a test
|
||
|
=================
|
||
|
|
||
|
In the simplest terms, a test is meant to look at the result of a particular
|
||
|
behavior, and make sure that result aligns with what you would expect.
|
||
|
Behavior is not something that can be empirically measured, which is why writing
|
||
|
tests can be challenging.
|
||
|
|
||
|
"Behavior" is the way in which some system **acts in response** to a particular
|
||
|
situation and/or stimuli. But exactly *how* or *why* something is done is not
|
||
|
quite as important as *what* was done.
|
||
|
|
||
|
You can think of a test as being broken down into four steps:
|
||
|
|
||
|
1. **Arrange**
|
||
|
2. **Act**
|
||
|
3. **Assert**
|
||
|
4. **Cleanup**
|
||
|
|
||
|
**Arrange** is where we prepare everything for our test. This means pretty
|
||
|
much everything except for the "**act**". It's lining up the dominoes so that
|
||
|
the **act** can do its thing in one, state-changing step. This can mean
|
||
|
preparing objects, starting/killing services, entering records into a database,
|
||
|
or even things like defining a URL to query, generating some credentials for a
|
||
|
user that doesn't exist yet, or just waiting for some process to finish.
|
||
|
|
||
|
**Act** is the singular, state-changing action that kicks off the **behavior**
|
||
|
we want to test. This behavior is what carries out the changing of the state of
|
||
|
the system under test (SUT), and it's the resulting changed state that we can
|
||
|
look at to make a judgement about the behavior. This typically takes the form of
|
||
|
a function/method call.
|
||
|
|
||
|
**Assert** is where we look at that resulting state and check if it looks how
|
||
|
we'd expect after the dust has settled. It's where we gather evidence to say the
|
||
|
behavior does or does not aligns with what we expect. The ``assert`` in our test
|
||
|
is where we take that measurement/observation and apply our judgement to it. If
|
||
|
something should be green, we'd say ``assert thing == "green"``.
|
||
|
|
||
|
**Cleanup** is where the test picks up after itself, so other tests aren't being
|
||
|
accidentally influenced by it.
|
||
|
|
||
|
At its core, the test is ultimately the **act** and **assert** steps, with the
|
||
|
**arrange** step only providing the context. **Behavior** exists between **act**
|
||
|
and **assert**.
|