Ask HN: How did you get better at unit testing?
Contracts I've worked in the past did not allow time for creating unit tests (sorry, non test-driven development shops). How did you learn how to write best-practice/elegant unit tests? Bonus points for python!
3 comments
[ 0.25 ms ] story [ 859 ms ] threadNo matter what, when you're writing code, you're doing "testing". That can either mean "run my code and see if it does what it's supposed to," or it can mean, "run a test that I wrote."
If you do the latter, the upfront time is longer -- maybe an hour -- but you save time by having automatic tests instead of manual tests.
A bad case for unit testing is when you feel that you are fighting with the apis you are using. If you are not so sure where your program ends and the stuff around it starts, that is bad for testing.
On the other hand, it is easy to write unit tests for integer arithmetic, string parsing, compilers, etc. If a subsystem is "functional" in the sense of no side effects, then testing is easy.
The book "working effectively with legacy code" systematically deconstructs the excuses people have about why code is not testable and shows you how to make it testable. Although the title mentions legacy code, it applies every bit as much to new code.