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.
