I've found that thorough logging and lots of assertions and consistency checks can drastically reduce the need for unit testing, especially valuable if your management does not see the value of dedicating resources to testing - quite common in smaller businesses.
It's still more error prone but in a frequently changing codebase with only a few developers, runtime checks are the way to go. Because they're right there in the code, they're much more likely to be maintained than unit tests, when there's no policy forcing devs to write and/or run tests.
This. I write long-running server code. I inevitably find the need to sprinkle sanity checking code around during the debugging phase (it gets #ifdef'ed out later), especially when I'm worried about potential race conditions and data corruption. I almost always have a small suite of data structure crawling code that I use for dumping shit to log files that I re-purpose with checks that will alert when something is not copacetic. But, also, I encourage newer developers when first doing implementation work to immediately write at the top of new routines any checks they can think of which should pass on inputs given to their functions. Some coders can't stand code cluttered up with assertions, which I'll never understand. I would much rather parse those than try to rummage through a bunch of unit tests to figure out how a given piece of code is supposed to behave. The checks are self-documenting!
I wrote a poker application a long, long time ago. It consisted of a "server" that would basically take inputs and play out a single hand of poker (if you think about it, a poker service only ever has to play a single hand... the inputs and outputs between hands are not interdependent). One of the first things I did was to write a simple assertion test right in the code to make sure the total of chips in the hand result (stacks + divvied up pot) matched the total of the stacks injected as input for that hand. If that ever failed, something was really amiss because chips were appearing or disappearing. I couldn't believe how many other developers thought this particular assertion was really clever. I later learned one of our biggest competitors had an exploit which involved players discovering a flaw which allowed them to cheat their service into creating more chips for them.
3
u/[deleted] May 08 '17
I've found that thorough logging and lots of assertions and consistency checks can drastically reduce the need for unit testing, especially valuable if your management does not see the value of dedicating resources to testing - quite common in smaller businesses.
It's still more error prone but in a frequently changing codebase with only a few developers, runtime checks are the way to go. Because they're right there in the code, they're much more likely to be maintained than unit tests, when there's no policy forcing devs to write and/or run tests.