It seems Python is now deprecating the imp standard library module, in favour of importlib. Eventually imp will go away. My Python unit test runner uses imp, so I will have to update it to use importlib. All my Python projects use my unit test runner. I suspect I won't be able to drop all my old Python projects in time (in favour of replacing them with other project, possibly written in Rust) to not have to convert things to importlib. Bummer. I dislike the extra work, but at least Python tends to do standard library transitions like this slowly, with clear deprecation warnings, and rarely, so I won't complain too much.

CoverageTestRunner runs Python unittest test suites under coverage.py, and measures test coverage for a module while running that module's unit tests, but ignoring accidental and incidental coverage from that unit getting called from other units. It fails the suite unless all statements are covered by unit tests, or the statements are explicitly marked as being excluded from coverage. I wrote it and use it because it's an easy way to get my projects into a state where I have high confidence that the code will work if it passes unit tests.

I don't really care about reaching "100% test coverage", but I do like being confident, and this approach means I don't accidentally leave something untested. Python's dynamic typing and general "scriptiness" mean that the rigour imposed by CoverageTestRunner has made me much more confident about changing my own code, and has saved me from numerous bugs.

A strongly, statically typed language with a good compiler, like Rust, or even C, gets much of the same benefit from the type system and the compiler, so there's much less need to aim for high unit test coverage to become confident about the code.

(If you with to comment on this blog post, please do so on Mastodon as a response to my toot. You can join an instance to do so.)