re: What was your TDD aha moment? VIEW POST

VIEW PARENT COMMENT VIEW FULL DISCUSSION

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.

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.

code of conduct - report abuse