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

expecting you to use

List()

and

.save()

, you’ll get failing tests even though the actual

effect of the code would be the same. If you’re not careful, this can start to work against

one of the supposed benefits of having tests, which was to encourage refactoring. You

can find yourself having to change dozens of mocky tests and contract tests when you

want to change an internal API.

Notice that this may be more of a problem when you’re dealing with an API you don’t

control. You may remember the contortions we had to go through to test our form,

mocking out two Django model classes and using

side_effect

to check on the state of

the world. If you’re writing code that’s totally under your own control, you’re likely to

design your internal APIs so that they are cleaner and require less contortions to test.

But All These Problems Can Be Overcome

But, isolation advocates will come back and say, all that stuff can be mitigated, you just

need to get better at writing isolated tests, and, remember the holy flow state? The holy

flow state!

So where are we?

Synthesis: What Do We Want from Our Tests, Anyway?

Let’s step back and have a think about what benefits we want our tests to deliver. Why

are we writing them in the first place?

Correctness

We want our application to be free of bugs—both low-level logic errors, like off-by-one

errors, and high-level bugs like the software ultimately should deliver what our users

want. We want to find out if we ever introduce regressions which break something that

used to work, and we want to find that out before our users see something broken. We

expect our tests to tell us our application is correct.

Clean, Maintainable Code

We want our code to obey rules like “YAGNI” and “DRY”. We want code that clearly

expresses its intentions, which is broken up into sensible components that have well-

defined responsibilities and are easily understood. We expect our tests to give us the

confidence to refactor our application constantly, so that we’re never scared to try and

improve its design, and we would also like it if they would actively help us to find the

right design.

Synthesis: What Do We Want from Our Tests, Anyway?

|

401