You inherited a .NET codebase with zero tests. Now what?

Every .NET developer has had that moment. You join a new team, clone the repo, open the solution, and see 200+ files. You check the test project — it's either empty, missing, or has three tests from 2019 that no longer compile. Your manager asks in the standup: "Can you add some tests to improve our confidence before we ship?" Sure. But where do you start? The two wrong answers Most people default to one of two strategies: Strategy A: Start from the top. Open the first file alphabetically, write tests. Move to the next. This is satisfying in the same way cleaning your desk is satisfying — it feels like progress but doesn't address the actual risk. You end up testing AccountHelper.cs (which hasn't been touched in two years) while PaymentProcessor.cs (37 commits this quarter, zero coverage) quietly ships bugs to production. Strategy B: Test whatever you touched last. This is reactive. You fix a bug, write a test for that bug, move on. Better than nothing, but it's not a strategy — it's a