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

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