Ask HN: Do you write tests before the implementation?

There's two basic kinds of code I write: the kind where I know what I'm doing before I start, and the kind where I don't.

For the latter, its when I'm exploring a codebase or an API, writing a spike script just to see how things work and what kinds of values get returned, for example. Many times I'll turn the spike into a test of some sort, but a lot of times I just toss it when I'm through.

For the former, yes, I generally write tests before implementation, though I'm not religious about it. I'm just lazy. I'm going to have to test the code I write somehow, whether that's by checking the output in a repl or looking at (for example) its output on the command line. Why you wouldn't want to capture that effort into a reproducible form is beyond me. (And if you're one of those people who just writes up something and throws it into production, I really hope we don't end up on a team together!) I generally just write the test with the code I wish I had, make it pass somehow, rinse repeat. Its not rocket science. Its just a good scaffold to write my implementation against.

That said, I don't usually keep every test I write. As others have noted, that code becomes a fixed point that you have to deal with in order to evolve your code, and over time it can become counterproductive to keep fixing it when you change your implementation slightly. So the stuff I keep generally has one of three qualities: * it documents and tests a public interface for the API, a contract it makes with client code * it tests edge cases and/or bugs that represent regressions * it tests particularly pathological implementations or algorithms that are highly sensitive to change.

Honestly, I feel like people who get religious about TDD are doing it wrong, but people who never do TDD (i.e. writing a test first) are also doing it wrong in a different way. There's nothing wrong with test-soon per se, but if you're never dipping into documenting your intended use with a test before you start working on the implementation itself, you're really just coding reactively instead of planning it, and it would not surprise me to hear lots of complaints in your office about hard-to-use APIs.

I follow a practice I like to call "test minded development".

I write tests at the earliest point I feel appropriate - but rarely before I actually write code. I tend to work on greenfield projects, so writing tests before I write code rarely makes sense.

IMO, TDD only makes sense if you already know what you're going to write. This makes a lot of sense if you're working on a brownfield project or following predictable patterns (for example, adding a method to a Rails controller).

If I'm doing actual new development, as I code, I tend to write a lot of pending tests describing the situations I need to test. However, I don't typically implement those tests until after.

One of the biggest factors for me is so much of my code deals with handling some degree of unknown - what the client will need, exact how an API works, how errors/invalidations are handled, unexpected refactoring, etc.

In this case, it doesn't make sense to create tests before I write the underlying code. Most tests will have mocks/stubs/simulations that make assumptions about how the code works. At that point, a pre-written test is no better than code, since it's just as likely to contain errors.

I much rather do real-time debugging/interacting while developing then capture the exact interactions of outside systems.

IMO, snapshots, like Jest/React, are one of my favorite ways to test UIs. They require minimal effort and address the major points of testing a UI.

Actual pixel "perfect" UI testing should still be done from time to time in a real browser. It's nearly impossible to properly capture some of the layout differences/bug that can come simply from a new browser version.

When people say writing tests first slows you down, they are usually only looking at the upfront costs. They do not factor in the costs of maintenance, and having to fix and/or extend a previously written code.

Send my best regards to Steven. I share the views as his.

Have you ever wondered why it became partisan to begin with?

Lots of other issues are not partisan like "smoking causes cancer", everyone generally agrees that it does, even many years ago before the "science proved it".

There is some science that is so obviously manipulated by power and money everyone knows something is wrong, but can't do anything about it.