Hacker News Reader

Comment by meheleventyone | Hacker News Reader

Whilst I very much agree with the premise I do think this exposes a fallacy many programmers fall for. That passing unit tests means your code actually does what you think it does. Using unit tests this way is a crutch to avoid improving startup times, implementing hot reloading and other schemes to skip gameplay. You lose an awful lot by not testing your code for the job it’s actually expected to do in situ. In games this results in increasing the total iteration time as it’s usually now a different person who actually runs the code, find issues and submits them back.

View on HN

Isn't the normal process, roughly, to:

1) Use unit tests to move quickly through to implementing The Feature 2) When The Feature is complete, run in a local environment to confirm it works 3) When that works, move The Feature to a development environment that more closely mimics Prod 4) Deploy to Prod

Each one of those steps takes an order of magnitude longer than the previous one, so should be done an order of magnitude less often. However if you are finding inconsistencies between steps, then alter local/dev to ensure more consistent testing. (i.e. if it works on Dev, it should just work on Prod, however there are always little issues).

Right but 2 often ends up being perfunctory whereas if you can test routinely against the local environment you’ll see a lot more and for example course correct earlier. It depends on what you’d consider an iteration as well. I don’t think the loop is closed until you’ve seen your code running in situ. Unit tests might let you have more confidence that things will work at that point.

Running in situ could also be integration testing FWIW. Depends on what it is you’re making.

No unit test should be mostly to make sure the old assumptions for code you don't know still hold and warn you if you break something.

Ofc if you do the code and the unit test, all you validate is that the code does what you assumed was right. But in 2 years, when someone touches something unrelated, he'll kiss you on the mouth that your test noticed an edge case that started failing.

If it's not your unit test catching unintended changes, it's your client. You may not want that :)

I'm not arguing against unit tests. Just that using them to speed up iteration is not a good way to approach that problem. They can of course be useful for other things. And obviously the things they don't test will still be found by the client in particular all the things you miss by not actually increasing iteration speed.

You need both. If you don't have unit tests your feed back loop becomes way too slow, but then you of course have to test the "real" running of the program properly before shipping. And you need at least one person who didn't write the code to test it.

Unit tests are useful for some things. I can’t unit test my way to a game feeling good. For that I need a fast feedback loop to the real program. There’s more of that in most applications than most people suspect. And routes to get there. As programmers we make a lot of little decisions along the way and those don’t get proper consideration unless you can see that as the feature evolves.

Reply on news.ycombinator.com