Ask HN: Do you write tests before the implementation?

> You're just trying things and seeing if some api gives you what you want or works as you might expect.

I don't do most of my programming this way, because mostly I'm writing new things, not gluing together existing APIs with a tiny amount of simple glue code. But when I do need to characterize existing APIs, I find that unit tests are a really helpful way to do it — especially in languages without REPLs, but even in languages that do have REPLs, because the tests allow me to change things (parameters, auth keys, versions of Somebody Else's Software) and verify that the beliefs I based my code on are still valid.

I'm wary of "testing theater" (in the spirit of "security theater"); but I've come to think of testing as similar to two-factor authentication: it doesn't guarantee correctness, but it does reduce the likelihood of bugs and regressions, especially during refactors.

I think the other benefit of testability has nothing to do with the tests themselves, but rather the discipline of writing testable code: in general, writing code that is easy to test will tend to be higher-quality and easier to reason about.

The thing I'm not fully sold on is mocking, which ends up being a huge timesink, and may or may not improve reliability since you're testing against a fake system and not the real thing. I vastly prefer a combination of small functional/unit tests, and E2E integration tests in a real environment (cypress/etc); the uncanny valley in between has a poor ROI IMO.

I accept the reality of global warming (I'm almost a single-issue voter on the subject), but I look at it from a Bayesian point of view: if we compared two universes, one where AGW was real, and one where the scientific consensus was mistaken (not exactly unprecedented), popular opinion would probably vary by no more than 1% between the two.

Humans tend to start with moral intuitions and tribal affiliations, and then cherry-pick data to support them; that irrational force is at work even in the cases where tribal values-signaling happens to align perfectly with reality.

It depends on the specific situation whether or not I write tests before, during or after feature development. But having experienced the benefits of having a reliable test suite, I can now never go back to not having one. Gives so much more confidence of things working and especially not breaking.

I will usually write one or a few tests that exercise ideal 'happy paths' before starting proper implementation, assuming it can be done fairly quickly. I don't hold on to these very tightly; they will often change as things go forward.

Once I have those basic tests passing, I will often write a couple more tests for less common but still important execution paths. It's ok if these take a little longer, but only a little.

Beyond the obvious 'test driven' benefits, I find that, especially for the first round, writing those tests helps me solidify what I'm trying to accomplish.

This is often useful even in cases where I go in feeling quite confident about the approach, but there are some blind spots that are revealed even with the first level, most simple tests.

I find the basic complaints that others have posted here about pre-writing tests largely valid. "Over-writing" tests too early on is, for me, often a waste of time. It works best when the very early tests can be written quickly and simple.

And if they can't be, then I'll frequently take a step back and see if I'm coming at the problem from a poor direction.