When I write new code, I try to get high statement coverage in the corresponding unit tests. However, the other day, there were two cases where I decided against writing extra unit tests.
In one case, it was a two-line method that made an API call to a third-party resource. I figured that factoring out that call into its own method was enough, and it wasn’t worth writing the associated unit tests and mocks.
In another case, I had declined to write the unit tests for illegal inputs to the method. In those cases, the method writes an error message to the logfile and throws an exception. I figured it wasn’t worth going through the additional effort for testing against those particular inputs that shouldn’t be happening in the first place.
Of course, there ended up being defects in both methods. In the two-liner, I was accessing a variable that hadn’t been defined, because I had pulled that method out from elsewhere and hadn’t made all of the appropriate changes. In the other case, I had forgotten the “%” that’s required for string interpolation in Python when writing error messages out to the log.
In a statically typed language, those errors probably would have been caught by the compiler. In a dynamic language like Python, where you don’t have the compiler doing these kinds of checks, you really do need to get very high coverage on your unit tests to catch these kinds of problems earlier.
Lorin's Tech Blog 