How do we make KUnit work for us?
summary
KUnit converts a slow, hard-to-run binder selftest into a fast suite that compiles and runs in ~25s on UML and ~35s on QEMU and exercises 75,000 combinations, but kernel unit testing hits three real barriers: function redirection currently forces source changes and ugly macros, Android’s module‑loaded tests prevent early‑init or build‑time compiler workarounds, and pervasive shared global state breaks isolation. The options are add careful KUnit features, refactor code for testability (costing memory or modularity), or run out‑of‑tree simulators like Clocknet Sim or kfuz with maintenance tradeoffs.
AI-written summary · about
chapters (8)
- 0:00Introduction to KUnit
- 1:26Strengths and weaknesses of unit testing
- 3:58Why KUnit is useful in practice
- 6:28Challenges of kernel unit testing
- 9:17Solutions to testing challenges
- 11:45Is KUnit the right tool?
- 13:12KUnit in Android CTS and production
- 14:38Q&A on KUnit and testing strategies
related talks
30mKernel Testing with KUnit: Bridging the Gap
44mKUnit - Unit Testing for the Linux Kernel
45m"KUnit: Past, Present, and Future"
28mTesting Drivers with KUnit (Does hardware have to be hard?)- 45mKUnit: Past, Present, and Future
18mKUnit: Function Redirection and More
19mHow to introduce KUnit to physical...
43mEffective Unit testing with Kotlin