KUnit Testing Framework

A sizable part of kernel development is taken up with testing, debugging, and speed evaluation. Even the revision control system includes the git bisect operation to quickly find which patch introduced a given bug. There are whole bug classes that, if not caught before the developer submits the patch, will get a stern rebuke from Linus Torvalds.

One type of test that has recently come to the Linux kernel is unit testing. Brendan Higgins introduced KUnit for consideration to the Linux Kernel Mailing List. The idea of unit tests is that code can be tested completely independently from the rest of the system. A given subroutine is tested solely for the action it performs. This is in contrast to other forms of testing, where code is so interconnected throughout the system that it can only be tested indirectly, by examining the behavior of a full running kernel. Unlike those more complex tests, unit tests are typically simple and repeatable, test a single thing, and give an immediate result. They are also fast and able to perform many tests in just a few seconds.

The response was a lot of enthusiasm for this work, especially from developers who had been rigging up their own unit tests on a case-by-case basis. Daniel Vetter was one of these, creating unit tests for the Direct Rendering Manager (DRM) driver. As he put it, "Having proper and standardized infrastructure for kernel unit tests sounds terrific. In other words: I want." And Dan Williams had been doing a similar thing for the libnvdimm driver. He said he planned to convert all of his unit tests to use KUnit.

[...]