<figure>

```pikchr
$margin = 0.4cm
boxht = 1cm
boxwid = 1.5cm
$dx = 1.5cm
$dy = 1.5cm
$td = 1.4cm

    arrow "make" above;
BC: box "base" "case" fill bisque;
    arrow 4cm;
BR: box "result" fill honeydew;

DC1: box "derived" "case 1" at BC+($dx,-$dy) same as BC
DC2: box "derived" "case 2" at $dy south of DC1 same as BC

R1:  box "result" at $dy south of BR same as BR
R2:  box "result" at $dy south of R1 same as BR

    arrow from DC1 to R1 chop
    arrow from DC2 to R2 chop
ML: line from BC.s down until even with DC2
    arrow to DC2 chop
    arrow from (ML.x, DC1.y) to DC1 chop


L1: line dashed from (DC1.e.x+$margin, BC.n.y+$margin) down until even with DC2.s-(0,$margin);
L2: line dashed from (R1.w.x-$margin, BC.n.y+$margin) down until even with DC2.s-(0,$margin);

## Labels

text at $td right of BR "expect" "happy" "case"
text at $td right of R1 "expect" "corner" "case 1"
text at $td right of R2 "expect" "corner" "case 2"

text at (DC1.x,L1.n.y) "set up"
text at (R1.x,L1.n.y) "verify result"
text at 1/2<L1.n,L2.n> "exercise";
line invis from ML.end to ML.start "modify" above aligned;
```

<figcaption>A diagram of how different tests share common test setup with a shared base fixture</figcaption>
</figure>

**Q**: How do you know you can trust your test set-up?<br>
**A**: You reuse a well-known test set up in every test.

## Example code

```python
def test_simple():
  req = set_up_working_request()
  resp = invoke(req)
  assert resp.status == OK

def test_invalid_page_size():
  req = set_up_working_request()
  req.page_size = -5
  resp = invoke(req)
  assert resp.status == INVALID_ARGUMENT
```

In the test,

*  We call `set_up_working_request()` and we know this results in
   "working" behavior.  Then we purposefully inject a defective
   negative page size into the working request.
*  We exercise the system under test in the same way.
*  We expect a different result.

Because the only difference in set up between `test_simple` and
`test_invalid_page_size` was in the differing page size, we can easily
reason that the different response status is resulting from just that.

## Related techniques

This works well together with these techniques:

*  Structure your test methods with **separate set up, exercise and
   verify phases**.[^fourphasetest]
*  Use **explicit helper functions for set up** and possibly name them
   according to expected behavior such as "working" in the example
   above.
*  Keep the shared **set up code in test methods as short as
   possible**, so that it's easy to spot the equal parts.
*  **1:N**: Use one base scenario (e.g. "working") and use its set up
   as a base for multiple derived scenarios.

[^fourphasetest]: This is called the "Four-Phase test" in the xUnit
    test pattern book. ([Meszaros07, p358][Meszaros07])

[Meszaros07]: https://martinfowler.com/books/meszaros.html