3 ms·
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 ta
by z3t4 7y ago
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.
- bluGill 7y agoThat 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.
- z3t4 7y agoI 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.
- toastal 7y agoThat'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.