Are you saying you write your entire test suite before writing any code? I thought tests were usually written before writing each individual method.
No, you do not write your entire test suite first. That is impossible. You will never get a ticket, task, project in a state which would allow this.
You write tests for as long as you can answer questions coming up. Then implement and verify. If that produces further questions, you produce further tests to implement and verify. Until all questions are answered.
Then you should reach a state where you can either clearly say: this makes sense. Or: this is crap, let's go back to the drawing board.
To make things simple, think of TDD like making a food plan for the next week(s). You come up with a generic plan as to what kind of vegetables, meat, etc you want.
From there on you drill down to actual recipes, then to actual cooking.
TDD is like that but without food. Sadly.
Sorry if this sounds dense. I'm not familiar with the official TDD methodology other than the concept of writing tests before coding (I have tried that, and found it's useful in a lot of cases). But this just sounds like making a top-down design and project planning in general, which doesn't (necessarily) require TDD.
Is it just that, when you finally do coding part by writing tests first, you find that it's more likely you're able to follow the plan and stay within the schedule? Or does TDD prescribe specific methods of project planning and top-down design?
No worries, these questions are the right ones to ask. If you consider TDD you have to verify if that is the right approach!
TDD is a good complementary process for design and project planning. It helps you proof check what you planned, or even see if something was planned at all. Moonshots are not uncommon, TDD would reveal them.
TDD definitely lets you stay within the schedule most of the time, and after a while, you can even be much faster than planned because TDD also trains your brain in doing the least amount of work to achieve the goal.
TDD does not require planning at all. You can start a project with just a moonshot, a bunch of ideas, and then use TDD to map these out. And this is probably the essence of TDD.
Whatever you build, TDD gives you an approach to turn an idea/plan into something actionable that can be verified and quantified. In answer "will it work" on a technical level.
And while we're at it: keep asking. If anything I learned that asking questions where you feel like these might be stupid is a great way to understand things and not stupid at all.
What's a good resource for learning TDD?
That really depends on you, and the language you want to learn in.
One resource I recently stumbled over is Test with Go. While Go may not be your preferred language, this course does a quite decent job of introducing test concepts, and thanks to how Go works, you also get to see both the good and the ugly sides of testing.
For getting into the spirit of TDD, I would recommend researching the topic of code katas. It is basically you repeatedly implementing a generic thing in a language of your choice using test driven methods. Many cities have local code kata groups, which I would recommend as TDD works best when challenged by another person.
E.g. having a colleague to implement code you wrote tests for and switching with each iteration is a great experience.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.