Don’t skimp on the unit tests

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.

Advertisements
This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s