You chose this option:
Start by reading the requirements carefully. Every time you find something that will need a test case, highlight it. Spend considerable time analysing each highlighted case and identifying edge cases, invariants etc. When you’re ready, go to a code editor and declare a test case for each thing you highlighted. Define custom assertions and supporting fixture code as needed. Comment out all but the first test case.
This option represents a serious investment in test analysis and design before any coding of the solution. It’s admirable that you have such high ambitions for your test code, and I’d hope for some really solid test cases. The danger is that you invest a lot before you really know the shape of the solution code. You might write more tests than are needed to prove the code works, or end up designing them in a way that will need a lot of refactoring later. I’d recommend a more lightweight analysis and an iterative process to improve the tests as the solution takes shape. Take a look at Option B for more information.