Ask HN: Do you write tests before the implementation?

> Committing the red test and the fix to the test in two commits makes the bug and its fix easy to review.

I've done this in the past. Then I started to use `git bisect` and having a red test somewhere in your commit-history is a killer for bisect. So now I tend to include both, the test and the bug-fix, within one commit.

Yes, I am pretty consistent in it. It has the great benefit of leading to highly reliable software even in the face of complex requirements and many requests for changes.

Rewriting the tests completely does not really happen. Sometimes I am not entirely sure of all the things that the production code should do so then I go back an forth between test and executable code. In that case one needs to be very aware of whether a failure is a problem in the executable code or the test code.

It pretty much works all the time. Occasionally there are the exceptions. If a thing is only visual, e.g., in a webinterface it may be best to first write the production code because the browser in my head may not be good enough to write a correct test for it. Also, in the case of code that is more on the scientific/numeric side of things one may start out with more executable code per test than one usually would. I still write the test first in that case, though.

cannot agree more. i've worked for a year on a fast evolving software and we had to refactor things a lot. TDD helped me to refactor in confidence and without regressions. Now i can't live without tests!

This is a great hoax in software industry. I generally use it for conversation starter in company's lunch

Personally, nope.

I could write a test plan first, but I haven't always fully designed the interfaces until I've ploughed into the code and figured out what needs to be passed where, so there would be a lot of repeat effort in fixing up the tests afterwards.

Effectively, in writing tests first you make assumptions about the code. These don't always turn out to be true.