## TL;DR This revision removes dependence on kunit_stream in favor of kunit_assert, as suggested by Stephen Boyd. kunit_assert provides a more structured interface for constructing messages and allows most required data to be stored on the stack for most expectations until it is determined that a failure message must be produced. As a part of introducing kunit_assert, expectations (KUNIT_EXPECT_*) and assertions (KUNIT_ASSERT_*) have been substantially refactored. Nevertheless, behavior should be the same. As this revision, adds a new patch, it, [PATCH v12 04/18], needs to be reviewed. All other patches have appropriate reviews and acks. I also rebased the patchset on v5.3-rc3. ## Background 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 (however, KUnit still allows you to run tests on test machines or in VMs if you want[1]) 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 about 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 makes unit tests deterministic: a failing unit test always indicates a problem. Finally, because unit tests necessarily have finer granularity, they are able to test all code paths easily solving the classic problem of difficulty in exercising error handling code. ### Is KUnit trying to replace other testing frameworks for the kernel? No. Most existing tests for the Linux kernel are end-to-end tests, which have their place. A well tested system has lots of unit tests, a reasonable number of integration tests, and some end-to-end tests. KUnit is just trying to address the unit test space which is currently not being addressed. ### More information on KUnit There is a bunch of documentation near the end of this patch set that describes how to use KUnit and best practices for writing unit tests. For convenience I am hosting the compiled docs here[2]. Additionally for convenience, I have applied these patches to a branch[3]. The repo may be cloned with: git clone https://kunit.googlesource.com/linux This patchset is on the kunit/rfc/v5.3/v12 branch. ## Changes Since Last Version - Dropped patch "[PATCH v11 04/18] kunit: test: add kunit_stream a std::stream like logger" and replaced it with "[PATCH v12 04/18] kunit: test: add assertion printing library", which provides a totally new mechanism for constructing expectation/assertion failure messages. - Substantially refactored expectations and assertions definitions in [PATCH 05/18] and [PATCH 11/18] respectively. - Rebased patchset on v5.3-rc3. - Fixed a minor documentation bug. [1] https://google.github.io/kunit-docs/third_party/kernel/docs/usage.html#kunit-on-non-uml-architectures [2] https://google.github.io/kunit-docs/third_party/kernel/docs/ [3] https://kunit.googlesource.com/linux/+/kunit/rfc/v5.3/v12 -- 2.23.0.rc1.153.gdeed80330f-goog
