요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.
1. 요약·해설
원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.
2. 영어 원문 전체
번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.
원문 전체 펼치기
.. SPDX-License-Identifier: GPL-2.0
==========================
Frequently Asked Questions
==========================
How is this different from Autotest, kselftest, and so on?
==========================================================
KUnit is a unit testing framework. Autotest, kselftest (and some others) are
not.
A `unit test <https://martinfowler.com/bliki/UnitTest.html>`_ is supposed to
test a single unit of code in isolation and hence the name *unit test*. A unit
test should be the finest granularity of testing and should allow all possible
code paths to be tested in the code under test. This is only possible if the
code under test is small and does not have any external dependencies outside of
the test's control like hardware.
There are no testing frameworks currently available for the kernel that do not
require installing the kernel on a test machine or in a virtual machine. All
testing frameworks require tests to be written in userspace and run on the
kernel under test. This is true for Autotest, kselftest, and some others,
disqualifying any of them from being considered unit testing frameworks.
Does KUnit support running on architectures other than UML?
===========================================================
Yes, mostly.
For the most part, the KUnit core framework (what we use to write the tests)
can compile to any architecture. It compiles like just another part of the
kernel and runs when the kernel boots, or when built as a module, when the
module is loaded. However, there is infrastructure, like the KUnit Wrapper
(``tools/testing/kunit/kunit.py``) that might not support some architectures
(see :ref:`kunit-on-qemu`).
In short, yes, you can run KUnit on other architectures, but it might require
more work than using KUnit on UML.
For more information, see :ref:`kunit-on-non-uml`.
.. _kinds-of-tests:
What is the difference between a unit test and other kinds of tests?
====================================================================
Most existing tests for the Linux kernel would be categorized as an integration
test, or an end-to-end test.
- A unit test is supposed to test a single unit of code in isolation. A unit
test should be the finest granularity of testing and, as such, allows all
possible code paths to be tested in the code under test. This is only possible
if the code under test is small and does not have any external dependencies
outside of the test's control like hardware.
- An integration test tests the interaction between a minimal set of components,
usually just two or three. For example, someone might write an integration
test to test the interaction between a driver and a piece of hardware, or to
test the interaction between the userspace libraries the kernel provides and
the kernel itself. However, one of these tests would probably not test the
entire kernel along with hardware interactions and interactions with the
userspace.
- An end-to-end test usually tests the entire system from the perspective of the
code under test. For example, someone might write an end-to-end test for the
kernel by installing a production configuration of the kernel on production
hardware with a production userspace and then trying to exercise some behavior
that depends on interactions between the hardware, the kernel, and userspace.
KUnit is not working, what should I do?
=======================================
Unfortunately, there are a number of things which can break, but here are some
things to try.
1. Run ``./tools/testing/kunit/kunit.py run`` with the ``--raw_output``
parameter. This might show details or error messages hidden by the kunit_tool
parser.
2. Instead of running ``kunit.py run``, try running ``kunit.py config``,
``kunit.py build``, and ``kunit.py exec`` independently. This can help track
down where an issue is occurring. (If you think the parser is at fault, you
can run it manually against ``stdin`` or a file with ``kunit.py parse``.)
3. Running the UML kernel directly can often reveal issues or error messages,
``kunit_tool`` ignores. This should be as simple as running ``./vmlinux``
after building the UML kernel (for example, by using ``kunit.py build``).
Note that UML has some unusual requirements (such as the host having a tmpfs
filesystem mounted), and has had issues in the past when built statically and
the host has KASLR enabled. (On older host kernels, you may need to run
``setarch `uname -m` -R ./vmlinux`` to disable KASLR.)
4. Make sure the kernel .config has ``CONFIG_KUNIT=y`` and at least one test
(e.g. ``CONFIG_KUNIT_EXAMPLE_TEST=y``). kunit_tool will keep its .config
around, so you can see what config was used after running ``kunit.py run``.
It also preserves any config changes you might make, so you can
enable/disable things with ``make ARCH=um menuconfig`` or similar, and then
re-run kunit_tool.
5. Try to run ``make ARCH=um defconfig`` before running ``kunit.py run``. This
may help clean up any residual config items which could be causing problems.
6. Finally, try running KUnit outside UML. KUnit and KUnit tests can be
built into any kernel, or can be built as a module and loaded at runtime.
Doing so should allow you to determine if UML is causing the issue you're
seeing. When tests are built-in, they will execute when the kernel boots, and
modules will automatically execute associated tests when loaded. Test results
can be collected from ``/sys/kernel/debug/kunit/<test suite>/results``, and
can be parsed with ``kunit.py parse``. For more details, see :ref:`kunit-on-qemu`.
If none of the above tricks help, you are always welcome to email any issues to
3. 한국어 전문 번역
영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.
Autotest와 kselftest와의 차이
1-24SPDX 라이선스 식별자: GPL-2.0
자주 묻는 질문
Autotest, kselftest 등과 무엇이 다른가요?
KUnit은 unit testing framework입니다. Autotest, kselftest와 일부 다른 도구는 unit testing framework가 아닙니다.
Unit test는 하나의 코드 단위를 격리하여 검사하므로 unit test라고 부릅니다. 가장 세밀한 testing granularity를 가져야 하고 검사 대상 코드의 가능한 모든 code path를 실행할 수 있어야 합니다. 이는 검사 대상 코드가 작고 hardware처럼 테스트의 통제 밖에 있는 external dependency가 없을 때만 가능합니다. 참고: https://martinfowler.com/bliki/UnitTest.html
현재 커널용 testing framework 중 test machine이나 virtual machine에 커널을 설치할 필요가 없는 framework는 없습니다. 모두 userspace에서 테스트를 작성하고 검사할 kernel 위에서 실행해야 합니다. Autotest, kselftest 등도 마찬가지이므로 unit testing framework로 간주할 수 없습니다.
UML 이외 architecture 지원
25-43KUnit은 UML 이외의 architecture에서도 실행할 수 있나요?
대부분의 경우 가능합니다.
테스트 작성에 사용하는 KUnit core framework는 거의 모든 architecture에서 compile할 수 있습니다. Kernel의 다른 부분처럼 compile되어 kernel boot 때 실행되고, module로 build했다면 module을 load할 때 실행됩니다.
다만 `tools/testing/kunit/kunit.py`의 KUnit Wrapper 같은 infrastructure는 일부 architecture를 지원하지 않을 수 있습니다. `kunit-on-qemu` 참조를 확인하십시오.
요약하면 다른 architecture에서도 KUnit을 실행할 수 있지만 UML에서 사용하는 것보다 작업이 더 필요할 수 있습니다. 자세한 내용은 `kunit-on-non-uml` 참조를 확인하십시오.
원문의 `_kinds-of-tests` anchor는 다음 질문에서 test 종류를 비교하는 위치를 가리킵니다.
Unit, integration, end-to-end test 비교
44-66Unit test와 다른 종류의 테스트는 어떻게 다른가요?
기존 Linux kernel 테스트 대부분은 integration test 또는 end-to-end test로 분류됩니다.
Unit test는 한 코드 단위를 격리해 검사합니다. 가장 세밀한 granularity로 모든 code path를 검사할 수 있지만 검사 대상이 작고 hardware 같은 통제 밖의 external dependency가 없어야 합니다.
Integration test는 보통 두세 개 정도의 최소 component 집합 사이 상호작용을 검사합니다. Driver와 hardware의 상호작용이나 kernel이 제공하는 userspace library와 kernel 사이 상호작용을 검사하는 테스트가 예입니다. 일반적으로 전체 kernel, hardware, userspace의 모든 상호작용까지 한 번에 검사하지는 않습니다.
End-to-end test는 검사 대상 코드의 관점에서 전체 시스템을 검사합니다. 예를 들어 production hardware에 production configuration kernel과 production userspace를 설치하고 hardware, kernel, userspace의 상호작용에 의존하는 동작을 실행할 수 있습니다.
격리 수준과 dependency 범위에 따라 세 종류의 테스트를 구분합니다.
KUnit 문제 해결 순서
67-104KUnit이 동작하지 않으면 무엇을 해야 하나요?
고장 날 수 있는 지점이 여러 곳이므로 다음 방법을 시도하십시오.
1. `./tools/testing/kunit/kunit.py run --raw_output`을 실행합니다. kunit_tool parser가 숨긴 세부 정보나 error message를 볼 수 있습니다.
2. `kunit.py run` 대신 `kunit.py config`, `kunit.py build`, `kunit.py exec`를 따로 실행해 문제가 발생한 단계를 찾습니다. Parser 문제라고 생각하면 stdin이나 file을 입력으로 `kunit.py parse`를 직접 실행할 수 있습니다.
3. UML kernel을 직접 실행하면 `kunit_tool`이 무시하는 문제나 error message를 발견할 때가 많습니다. `kunit.py build` 등으로 UML kernel을 build한 뒤 `./vmlinux`를 실행하면 됩니다.
UML에는 host에 tmpfs filesystem이 mount되어 있어야 하는 등의 특별한 요구 사항이 있습니다. 또한 static build와 host KASLR을 함께 사용할 때 문제가 있었던 적이 있습니다. 오래된 host kernel에서는 KASLR을 끄기 위해 `setarch `uname -m` -R ./vmlinux`를 실행해야 할 수 있습니다.
4. Kernel `.config`에 `CONFIG_KUNIT=y`와 최소 한 테스트, 예를 들어 `CONFIG_KUNIT_EXAMPLE_TEST=y`가 있는지 확인합니다. kunit_tool은 사용한 `.config`를 유지하며 사용자가 적용한 변경도 보존합니다. `make ARCH=um menuconfig` 등으로 option을 활성화하거나 비활성화한 뒤 다시 실행할 수 있습니다.
5. `kunit.py run` 전에 `make ARCH=um defconfig`를 실행합니다. 문제를 일으킬 수 있는 남은 config item을 정리하는 데 도움이 됩니다.
6. 마지막으로 UML 밖에서 KUnit을 실행합니다. KUnit과 KUnit test는 어떤 kernel에도 built-in으로 넣거나 module로 build해 runtime에 load할 수 있습니다. 이를 통해 UML이 문제의 원인인지 판단할 수 있습니다.
Built-in 테스트는 kernel boot 때 실행되고 module은 load될 때 연결된 테스트를 자동으로 실행합니다. 결과는 `/sys/kernel/debug/kunit/<test suite>/results`에서 수집하고 `kunit.py parse`로 parsing할 수 있습니다. 자세한 내용은 `kunit-on-qemu` 참조를 확인하십시오.
위 방법으로 해결되지 않으면 [email protected]으로 문제를 보내도 됩니다.
Parser 출력부터 UML 분리 검증까지 원인을 좁혀 가는 순서입니다.
요약과 해설
faq.rst:1-104KUnit은 kernel code의 작은 단위를 격리해 모든 경로를 검사하는 unit framework이고, kselftest와 Autotest는 설치된 kernel과 userspace 경계를 포함하는 integration 성격의 framework입니다.
문제가 생기면 raw output 확인, config·build·exec·parse 단계 분리, UML 직접 실행, KUnit config 검증, non-UML 재현 순서로 원인을 좁힙니다. Built-in과 module test 결과는 debugfs에서 다시 수집해 parser에 넣을 수 있습니다.