If I got one afternoon with a new engineer before they touched a single testing tool, I would not open a framework. I would not show them a mocking library or a CI config. I would teach them two old ideas that have nothing to do with any specific technology, because in a decade of doing this I have found they matter more than any tool choice, and almost nobody teaches them first.
Both ideas are about the same thing underneath: sequencing your effort so you learn the expensive lessons cheaply. Here they are.
Idea one: confront the scariest thing first
The first idea I would steal directly from a process model most people write off as ancient history. Reading about the spiral model in software engineering years into my career reorganized how I think about testing effort, even though I have never run a formal spiral in my life.
The model's core move is simple and countercultural. Before building anything in a cycle, you ask: what is the single scariest unknown right now, and how do I test that assumption as cheaply as possible? Not the easiest thing. Not the thing that demos well. The thing most likely to be wrong in a way that hurts.
Most of us instinctively do the opposite. We test what is easy to test, because green checkmarks feel like progress and the scary integration or the sketchy concurrency case is unpleasant to confront. So we defer it, and we discover the problem late, when it is expensive and load-bearing. The spiral model's whole philosophy is a rebuke to that instinct: spend a little to learn the scary thing early, before you have built a mountain on top of an assumption that turns out to be false.
For a new engineer, this translates to one habit. When you sit down to test a feature, do not start with the part you understand. Start with the part that scares you, or that you are secretly unsure about. That is where the real bugs are, and finding them early is the cheapest they will ever be.
Idea two: know who the finding is for
The second idea is about matching the kind of testing to the kind of question, and the cleanest illustration of it is the distinction between alpha vs beta testing.
On the surface those are just two release phases. Underneath, they encode a principle that applies far beyond formal betas: different kinds of problems can only be found by different kinds of testers, and using the wrong one is waste. Alpha is internal, controlled, done by people who can read a stack trace. It is for finding out whether the thing works at all. Beta is external, messy, done by real users on real machines. It is for finding out whether the thing works for people who are not you, which is a question no internal team can answer no matter how skilled, because they are too close to the product to see it fresh.
The new engineer does not need to run betas to use this. They need the underlying reflex: before testing something, ask who is actually qualified to find the problem I am worried about. A machine can tell you the endpoint returns the wrong number. Only a confused human can tell you the feature is confusing. Pointing the wrong instrument at a problem either misses it or wastes an expensive resource on something a cheap one would have caught. Match the tester to the question.
Why these two and not, say, "learn pytest"
Tools change. The specific framework I would have taught a new engineer ten years ago is half-forgotten now, and whatever I taught today would age just as fast. These two ideas have not aged at all, because they are not about technology. They are about where to point finite attention.
And attention is the actual scarce resource. A new engineer's biggest risk is not that they do not know a tool. It is that they will spend their limited testing effort on the comfortable, easy, low-risk parts of the system and feel productive while the real dangers sit untested. Both ideas are antidotes to that specific failure. Confront the scary thing first so you do not defer the expensive lesson. Match the tester to the question so you do not waste the expensive instrument.
The afternoon, in one sentence
If I could only leave them with one line, it would be this: test the thing most likely to hurt you, with the instrument actually capable of catching it, before you spend your effort anywhere else. Everything about specific tools is downstream of getting that reflex right, and the tools will keep changing under you anyway.
The frameworks are learnable in a week whenever you need them. The judgment about where to aim takes years, and it is the part worth starting on day one. Start there, and the tools become details.
What is the one non-tool testing idea you wish someone had taught you before your first framework? I want to build a list worth handing to juniors.
Top comments (1)
Nothing builds confidence quite like a suite of green checkmarks that test absolutely nothing that could actually break. I have been there—watching the tests pass while the production server quietly catches fire behind me like a metaphor I refuse to acknowledge. The scary part is never the code I understand; it is the code I wrote quickly and hoped for the best.
This is the kind of post that should be required reading before anyone writes their first test. The spiral model insight in particular hit me hard, because I have spent years doing the exact opposite—testing the easy, safe, comfortable parts first because green feels good, and deferring the scary integration until it is load-bearing and expensive to fix. Confronting the scariest thing first is counterintuitive, but it is the only way to avoid building a mountain on a foundation that does not actually hold.
One thing I would add: the two ideas actually reinforce each other more than you might think. When you confront the scariest thing first, you are also forced to ask who is qualified to find that problem. The scary unknown is often the one that requires a specific kind of tester—maybe a user, maybe a performance test, maybe a chaos monkey. Matching the tester to the question becomes natural once you are already asking the hard question. They are not separate ideas; they are the same reflex applied to two different dimensions.
To your question at the end: I wish someone had taught me that "test coverage" is not a goal. It is a metric that tells you how much of your code is exercised, not how much of your risk is mitigated. 100% coverage with no scary-unknown tests is a false sense of security, and I spent way too long chasing that green number before I realized it was not actually keeping me safe.
Anyway, this is gold. I am bookmarking it for the next time I onboard someone. Thanks for writing something that is not just another "here is how to use Jest" post.