When I work the "usual way", I write my automated tests after the production code, which often feels difficult. I tend to judge that it's impossible to write a good test for this particular code. Thus, I skip writing the test.

· · Web · 1 · 0 · 0

With test-driven development, the whole situation gets flipped upside down.

If I now try to write code to make the test pass and find it difficult, it's an obvious sign that I need to take my ideas back to the design board. This saves me precious time as I have likely uncovered a design flaw or a defect early on in the process.

Fixing it now is faster and cheaper as opposed to fixing it after release.

For me, this was a great revelation when I was learning .

There are so many obstacles preventing you from writing untestable code, and that's a good thing.

Writing code is like producing steel: you create the mould (tests) first, then pour the liquid metal (implementation) into the mould.

If you first pour the liquid metal on a surface and then try to mould it for the desired outcome, you'll burn your hands and end up with something completely different from what you designed.

Sign in to participate in the conversation
Mastodon for Tech Folks

This Mastodon instance is for people interested in technology. Discussions aren't limited to technology, because tech folks shouldn't be limited to technology either!