Ask HN: Do you write tests before the implementation?

> Do you write tests before the implementation? Absolutely, day in day out. New code and bugs fixing a like. It's the proof that I need to know that whatever code I am doing is an exact fit to the problem it's trying to solve.

> Can you describe the practical benefit? Testing first help me clarify my intentions, then implement a realisation of those intentions through code. Testable code has the side effect of being well modularized, free from hidden dependencies, and SOLID.

And it's also about making sure that whatever code you write, there's a justification for it and a proof that it works, could be seen more like a harness protecting you from writing things that you don't need, YAGNI.

> Do you happen to rewrite the tests completely while doing the implementation? I follow the classic TDD cycle, RED/GREEN/REFACTOR and I can not be any happier.

> When does this approach work for you and when did it fail you? The only exception to the above is exploratory code. I.e. the times where I don't know how to solve a given problem, I like to hack few things together and poke the application and see what happens due to what I have changed.

Having verified and learned more about how to solve that problem, I delete all my code and start afresh but this time TDD the problem/solution equipped with what I have learned from my exploratory cycle.

If you are in doubt or need further information to help you make your own decision about the matter, I can not recommend enough the classic TDD by Example from Kent Beck as a starting point.

For a more real-world view with an eye on the benefits of adopting TDD, have a look at Growing Object Oriented Software Guided by Tests, aka the Goose book.

> With the kind of software I mostly write these days, I'm fortunate to be able to incrementally develop my code and test it under real-world conditions or a subset thereof.

What kind of software you write if you don't mind me asking ?and are your "real-world conditions" tests automated ?

> The upside is that I don't have to write "strange" code to accommodate testing.

Can you elaborate more as what you mean by "strange" ?

sometimes I do TDD for modules that are simultaneously developed for both frontend and backend (nodeJS)

This way I can mostly stay in the frontend where the tooling is better and the results are more visual, but still be confident that I don't violate the proper abstraction that the backend requires.

Kinda like predefining the shared module contract between front- and backend and forcing myself not to forget about it when in the (frontend) flow

I’ve always been highly skeptical of this approach. Often what you’re doing is so clear cut that tests are entirely unneeded. In fact, outside of the most complicated cases, I don’t even use unit tests. I have black box testing that I use to check for regression. My biggest reasoning for this is that test code is effectively another code base to maintain, and as soon as you start changing something it’s legacy code to maintain.

All that being said, I haven’t spent much time on teams with a particularly large group of people working in one project. I think the most has been 4 in one service. The more people working in a code base, the more utility you get from TDD, I believe. It’s just tough to have a solid grasp on everything when it changes rapidly.

This is a big topic, and you're asking some good questions. Rather than tackle it all, I can recommend expanding your questions with the following.

When someone tells you they don't write tests first, ask them how they refactor. How do they know the changes they made didn't break anything?

You can fool yourself with test-first, but it's quite difficult to do if you're rigorously following the practice. First write a failing test. Next, write only enough production code to fix the failing test. Optionally refactor. Rinse and repeat.

Code created this way can prove that every line of production code resulted from a failing test. Nothing is untested, by definition. The code may be incomplete due to cases not considered, but everything present has been tested. Note that it's possible to break this guarantee by writing production code unnecessary to get the test to pass.