I haven’t used TDD much but when I did I found I had that issue, that I would imagine the code I wanted to write and then write tests to check that I had written that code (obviously not the intent of TDD). I got a little better when I thought about testing requirements. I actually used an old trick I’d learned from the head of a web dev shop - when he was struggling to elicit requirements from a client in a meeting, he would hold up a pencil and say “does this fix your problem? why not?” and then inverting their objections would produce requirements more fluidly. (Obviously you don’t stay on the pencil for long, but it puts the client in the right mental state of “looking for lack of capabilities in proposed solution” rather than the more usual “bullet point shopping list of desired delivery levels, SLAs, etc”).
The idea that test design can actually constrain your solutions if your tests are too opinionated about implementation is fascinating.
Seems like maybe optimization needs to be a loop of "we optimize the code, then we optimize the tests"
Something to that effect.