Productive Workflow
Finally, we want our tests to help enable a fast and productive workflow. We want them
to help take some of the stress out of development, we want them to protect us from
stupid mistakes. We want them to help keep us in the “flow” state not just because we
enjoy it, but because it’s highly productive. We want our tests to give us feedback about
our work as quickly as possible, so that we can try out new ideas and evolve themquickly.
And we don’t want to feel like our tests are more of a hindrance than a help when it
comes to evolving our codebase.
Evaluate Your Tests Against the Benefits You Want from Them
I don’t think there are any universal rules about how many tests you should write and
what the correct balance between functional, integrated, and isolated tests should be.
Circumstances vary between projects. But, by thinking about all of your tests and asking
whether they are delivering the benefits you want, you can make some decisions.
Objective
Some considerations
Correctness
•
Do I have enough functional tests to reassure myself that my application
really
works, from the point of
view of the user?
•
Am I testing all the edge cases thoroughly? This feels like a job for low-level, isolated tests.
•
Do I have tests that check whether all my components fit together properly? Could some integrated tests
do this, or are functional tests enough?
Clean,
maintainable
code
•
Are my tests giving me the confidence to refactor my code, fearlessly and frequently?
•
Are my tests helping me to drive out a good design? If I have a lot of integrated tests and few isolated
tests, are there any parts of my application where putting in the effort to write more isolated tests would
give me better feedback about my design?
Productive
workflow
•
Are my feedback cycles as fast as I would like them? When do I get warned about bugs, and is there any
practical way to make that happen sooner?
•
If I have a lot of high-level, functional tests, that take a long time to run, and I have to wait overnight
to get feedback about accidental regressions, is there some way I could write some faster tests, integrated
tests perhaps, that would get me feedback quicker?
•
Can I run a subset of the full test suite when I need to?
•
Am I spending too much time waiting for tests to run, and thus less time in a productive flow state?
Architectural Solutions
There are also some architectural solutions that can help to get the most out of your test
suite, and particularly that help avoid some of the disadvantages of isolated tests.
Mainly these involve trying to identify the boundaries of your system—the points at
which your code interacts with external systems, like the database or the filesystem, or
402
|
Chapter 22: Fast Tests, Slow Tests, and Hot Lava