Having gone through the whole book, it is worth gathering it into one checkable picture: how to tell a professional test from an amateur one by looking at the code. This is not a checklist for the sake of ticks but a way of thinking - a set of questions an honest author asks before considering a test done. All the criteria below we have already covered separately; here they converge into one view, because it is together that they decide whether a test can be trusted.
First - the name. A good name describes the condition and the expected outcome in the language of behavior: 'returns an error for an empty email', not 'validation test'. From the name it should be clear what broke even before reading the body. Second - the test checks observable behavior, not private implementation: the result and the visible effect, not which internal method was called. The first survives refactoring, the second breaks at a rename.
Third - the significant classes of input are covered: normal, boundary, invalid and failure. It is the boundary and the error branch that most often hide bugs, and a single happy-path test does not see them. Fourth - independence: the result does not depend on the network, the clock, run order or shared state. A test green alone and red in the suite violates this criterion and does not deserve trust until the cause is removed.
Fifth - substitutions stand at real boundaries. A mock is justified on the network, the file system, the payment gateway, the system clock; mocking domain logic that can be passed as a dependency means checking your own stubs. Sixth - integration risk is covered by an integration test, not simulated by unit mocks: database behavior is checked with a real test database, not a mock ORM that will agree with anything.
Seventh - the failure reads. When a test goes red, from Expected/Received and the name it should be clear what exactly is wrong, without digging in the debugger for every case. A clear diff is part of the test's contract, not a nice bonus. Eighth, the summarizing one - safe refactoring must not break the test: if a behavior-preserving change fails the check, the test clings to the form of the implementation rather than the promise, and will hinder rather than protect.
| Criterion |
|---|
| Professional test |
|---|
| Amateur |
|---|
| Name | condition + outcome, behavior language | 'function test', 'works' |
|---|---|---|
| What it checks | observable behavior | a private call, internal method |
| Inputs | normal / boundary / invalid / failure | only the happy path |
| Independence | of network, clock, order, state | green alone, red in the suite |
| Substitutions | at a real boundary | a mock of domain logic |
| Integration | a real test database | a mock ORM agrees with anything |
| Failure | a clear Expected/Received | unclear what broke |
| Refactoring | unbroken under the same behavior | fails at a rename |
These eight points add up to the one principle for which the whole book is written. A test protects the code's observable promise, not the form of its implementation. The promise is what a user of a function, a component, an API sees and relies on: a given input yields a given output, an error is reported, the contract is honored. The form is how exactly it is all arranged inside, and it is entitled to change as long as the promise holds.
Hence the practical meaning of the whole discipline. Good tests give freedom to change the implementation without fear: while the promise is intact, the suite is silent, and the moment it is broken, it goes red precisely and to the point. Bad tests do the opposite - they tie themselves to the implementation and punish any refactoring, until the team starts to fear its own code. The difference is not in the tool or the number of tests but in what exactly they assert.
Check your test with these questions - and you will see not a coverage line but the promise it guards. Write a suite that tells the truth about behavior: silent while the promise holds, red exactly when it is broken. Such a suite is not bureaucracy or insurance for the sake of a metric but the thing that lets you change a system confidently for years. That is professional testing, not installing a tool and a tick in a report.