Those two steps aren't really trivial. Even just writing the single test might require making a lot of design decisions that you can't really make up-front without the code.
This acts as a forcing function for the software design. That TDD requires you to think about properly separating concerns via decomposition is a feature, not a bug. In my experience the architectural consequences are of greater value than the test coverage.
Sadly TDD is right up there with REST in being almost universally misunderstood.
Then you need to keep the test and signature in lock step. Your method signature is likely to change as the code evolves. I'm not arguing against tests but requiring them too early generates a lot of extra work.
