| Googler | 9398cc3 | 2022-12-02 17:21:52 +0800 | [diff] [blame^] | 1 | .. SPDX-License-Identifier: GPL-2.0 |
| 2 | |
| 3 | ========================== |
| 4 | Frequently Asked Questions |
| 5 | ========================== |
| 6 | |
| 7 | How is this different from Autotest, kselftest, etc? |
| 8 | ==================================================== |
| 9 | KUnit is a unit testing framework. Autotest, kselftest (and some others) are |
| 10 | not. |
| 11 | |
| 12 | A `unit test <https://martinfowler.com/bliki/UnitTest.html>`_ is supposed to |
| 13 | test a single unit of code in isolation, hence the name. A unit test should be |
| 14 | the finest granularity of testing and as such should allow all possible code |
| 15 | paths to be tested in the code under test; this is only possible if the code |
| 16 | under test is very small and does not have any external dependencies outside of |
| 17 | the test's control like hardware. |
| 18 | |
| 19 | There are no testing frameworks currently available for the kernel that do not |
| 20 | require installing the kernel on a test machine or in a VM and all require |
| 21 | tests to be written in userspace and run on the kernel under test; this is true |
| 22 | for Autotest, kselftest, and some others, disqualifying any of them from being |
| 23 | considered unit testing frameworks. |
| 24 | |
| 25 | Does KUnit support running on architectures other than UML? |
| 26 | =========================================================== |
| 27 | |
| 28 | Yes, well, mostly. |
| 29 | |
| 30 | For the most part, the KUnit core framework (what you use to write the tests) |
| 31 | can compile to any architecture; it compiles like just another part of the |
| 32 | kernel and runs when the kernel boots. However, there is some infrastructure, |
| 33 | like the KUnit Wrapper (``tools/testing/kunit/kunit.py``) that does not support |
| 34 | other architectures. |
| 35 | |
| 36 | In short, this means that, yes, you can run KUnit on other architectures, but |
| 37 | it might require more work than using KUnit on UML. |
| 38 | |
| 39 | For more information, see :ref:`kunit-on-non-uml`. |
| 40 | |
| 41 | What is the difference between a unit test and these other kinds of tests? |
| 42 | ========================================================================== |
| 43 | Most existing tests for the Linux kernel would be categorized as an integration |
| 44 | test, or an end-to-end test. |
| 45 | |
| 46 | - A unit test is supposed to test a single unit of code in isolation, hence the |
| 47 | name. A unit test should be the finest granularity of testing and as such |
| 48 | should allow all possible code paths to be tested in the code under test; this |
| 49 | is only possible if the code under test is very small and does not have any |
| 50 | external dependencies outside of the test's control like hardware. |
| 51 | - An integration test tests the interaction between a minimal set of components, |
| 52 | usually just two or three. For example, someone might write an integration |
| 53 | test to test the interaction between a driver and a piece of hardware, or to |
| 54 | test the interaction between the userspace libraries the kernel provides and |
| 55 | the kernel itself; however, one of these tests would probably not test the |
| 56 | entire kernel along with hardware interactions and interactions with the |
| 57 | userspace. |
| 58 | - An end-to-end test usually tests the entire system from the perspective of the |
| 59 | code under test. For example, someone might write an end-to-end test for the |
| 60 | kernel by installing a production configuration of the kernel on production |
| 61 | hardware with a production userspace and then trying to exercise some behavior |
| 62 | that depends on interactions between the hardware, the kernel, and userspace. |
