Hacker News Reader

Comment by josephg | Hacker News Reader

I used to make this argument, but I think I was wrong. I sort of hate working in javascript projects I’ve written with a million tests, because if I want to refactor something, it takes 3x as much work because of all the tests I need to rewrite.

Lately I’ve been really enjoying typescript and rust. The ability to write code and if it compiles run it and have it be correct is like a cool breeze on a summer day. In typescript I need to write fewer tests (because the compiler catches bugs that I would need a unit test for in JS). But also, when I refactor something the compiler gives me a list of all the places in my code which I need to update. In JS I have learned to worry about lingering bugs that I just forgot to write unit tests for or something. With a typed language, that fear is (mostly) gone. It’s a lovely quality of life improvement, and it noticeably improves my velocity.

View on HN

Unit tests and type checking solve very different problems. In practice there is a lot of overlap, but there are gaps in both that the other covers, thus you need both if you want the best quality (if you want the best quality you will also look at formal proofs which is a super set of type checking and can catch even more problems that the above two won't - but even that will not catch everything)

Unit tests prove that everything you thought of works correctly. Formal proofs show some ares where you didn't think of something still work - but they can fail because the assumptions are wrong.

I agree that you need both. But in my experience you need far fewer unit tests in a typed language in practice to be reasonably confident of correctness. Like, maybe 1/3 of the number of tests. The reason you need so many tests in JS is that its just so easy to accidentally refer to a variable that doesn’t exist anymore or something like that. And the only real way to be safe from that sort of mistake is to go overboard with unit tests and aim for 100% coverage, which destroys velocity.

As you say, unit tests and type systems are good for different things. Unit tests can be used as a poor mans type system, but that seems like an amateurish deal now we have typescript & friends. Well, at least for code you want to maintain long term.

I do not like traditional unit testing as the tests are glued to the code, then I would rather write assertions in-line together with the function! Instead I take a black-box approach, for example a HTTP server is tested by making actual HTTP requests to it. That way you do not have to rewrite the tests when you change the code - just add additional tests.

That's another checkmark for keeping functions pure so you can easily do substitution. Problems will arise if your language doesn't have managed IO because you can never be sure.

That is another useful way of testing. The problem with it is eventually you write some low level code and realize that sometime in the future someone is likely to use your new code in a way that will expose a bug - but right now something higher level prevents that bug, and you have no idea how to prevent it with assertions inline and the outside black box tests can't cover this case yet.

For large complex systems all levels of testing are needed to get the best quality.

I use defensive programming, as in throwing errors when something is used the wrong way. Assuming that the developer always run the code at least once before shipping. But I try to avoid thinking into the future. I'm already too good at finding edge cases, that if I would also think about possible issues that might arise in the future, I would get nothing done. I instead wait for it, and then fix it only when it has become an issue. Especially in optimization, I often fall into though traps like "what about when this table has millions of rows, this query would take a long time", I have to remind myself of the problem and what the priority is right now. While there is code debt, there is also opportunity cost.

If you're re-writing tests you're not refactoring you're just rewriting.

If tests need to be rewritten to support a refactor those aren't tests, they're at best just testing the implementation rather than requirements and at worst just a second implementation.

Reply on news.ycombinator.com