There isn't a one-size-fits-all approach to Test-Driven Development (TDD), and different developers and teams may find variations of the process that work best for them. The essence of TDD lies in the principles of writing tests before or alongside code to ensure better design, maintainability, and test coverage. However, the exact process and order of writing tests and code can vary based on individual preferences and project requirements.
One approach, where you first get a feel for the problem and write some code before diving into the test-code cycle, is a valid way of approaching TDD, especially if it helps you better understand the problem domain and the code you need to write. This can be particularly useful when starting a new project or dealing with complex scenarios. In XP that's called a spike, but it's not really a separate activity, the sooner you can figure out the "bit you don't get", then you jump into writing a test.
The "Red-Green-Refactor" cycle popularized by Kent Beck and Uncle Bob (Robert C. Martin) is a structured and methodical way to ensure that each piece of code is accompanied by tests. It helps in avoiding over-engineering, ensuring test coverage, and providing a safety net for refactoring. But, the exact process may vary.
Ultimately, the goal of TDD is to achieve well-tested, maintainable, and functional code. The approach you choose should align with the needs and dynamics of your project and team. The important thing is to ensure that tests are an integral part of the development process and that they help in achieving the desired outcomes.
If you've watched Robert C. Martin build things using the strict Red-Green-Refactor process, you'll know it's neat, but it can leave a lot to be desired. It's also worth pointing out that Bob is more of a professional author and speaker than, an in-the-trenches developer, so it can often be fairly tough to relate.
The stresses and strains of where business meets code, tends to force compromises. So do TDD in the way that ensures you have test cover as early as possible, but don't use it as an excuse not to think.
Having written software for over 40 years, I can tell you, having those tests is the #1 benefit. Even though you'll likely miss edge cases. Those tests keep the codebase maintainable, as it can't be broken without a test failing.
The #2 benefit is that things get built in isolation by default, so all your modularisation can be guided, mostly, by the TDD process + good old careful thought.
If I can recommend any book on the subject, it'd be Kent Beck's Test Driven Development. The rest are just rinse and repeat, or "when using X"