On 11/28/18 11:36 AM, Brendan Higgins wrote:
This patch set proposes KUnit, a lightweight unit testing and mocking framework for the Linux kernel.
Unlike Autotest and kselftest, KUnit is a true unit testing framework; it does not require installing the kernel on a test machine or in a VM and does not require tests to be written in userspace running on a host kernel. Additionally, KUnit is fast: From invocation to completion KUnit can run several dozen tests in under a second. Currently, the entire KUnit test suite for KUnit runs in under a second from the initial invocation (build time excluded).
KUnit is heavily inspired by JUnit, Python's unittest.mock, and Googletest/Googlemock for C++. KUnit provides facilities for defining unit test cases, grouping related test cases into test suites, providing common infrastructure for running tests, mocking, spying, and much more.
## What's so special about unit testing?
A unit test is supposed to test a single unit of code in isolation, hence the name. There should be no dependencies outside the control of the test; this means no external dependencies, which makes tests orders of magnitudes faster. Likewise, since there are no external dependencies, there are no hoops to jump through to run the tests. Additionally, this
This question might be a misunderstanding of the intent of some of the terminology in the above paragraph, so this is mostly a request for clarification.
With my pre-conception of what unit tests are, I read "test a single unit of code" to mean a relatively narrow piece of a subsystem. So if I understand correctly, taking examples from patch 17 "of: unittest: migrate tests to run on KUnit", each function call like KUNIT_ASSERT_NOT_ERR_OR_NULL(), KUNIT_EXPECT_STREQ_MSG(), and KUNIT_EXPECT_EQ_MSG() are each a separate unit test, and thus the paragraph says that each of these function calls should have no dependencies outside the test. Do I understand that correctly?
< snip >
-Frank