← Documents Documentation/dev-tools/ktap.rst GitHub 원문 ↗

Linux 6.18.37 · Dev Tools

The Kernel Test Anything Protocol (KTAP), version 1

KTAP version·plan·result·diagnostic line 문법, directive 의미, unknown line 처리, 중첩 테스트와 TAP 차이를 설명합니다.

Source pathDocumentation/dev-tools/ktap.rst
Source versionLinux v6.18.37
TranslationDUJINLABS 전문 번역 + 해설

요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.

1. 요약·해설

원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.

요약과 해설

ktap.rst:1-314

KTAP는 kernel test output을 machine-readable하게 만드는 TAP 확장 형식입니다. 각 level은 version line과 가능하면 plan line을 갖고, 순차 번호가 붙은 ok 또는 not ok 결과 뒤에 SKIP, XFAIL, TIMEOUT, ERROR 같은 directive와 diagnostic data를 덧붙입니다.

Kernel console에는 테스트와 무관한 출력이 섞일 수 있으므로 unknown line을 허용하며 결과 판정에는 반영하지 않습니다. 중첩된 subtest는 level마다 두 칸씩 들여쓰고 자체 version과 plan을 사용하며, 실패 결과는 parent로 전파하되 skip은 일반적으로 parent의 성공 또는 실패에 영향을 주지 않습니다.

2. 영어 원문 전체

번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.

원문 전체 펼치기
1 .. SPDX-License-Identifier: GPL-2.0
2
3 ===================================================
4 The Kernel Test Anything Protocol (KTAP), version 1
5 ===================================================
6
7 TAP, or the Test Anything Protocol is a format for specifying test results used
8 by a number of projects. Its website and specification are found at this `link
9 <https://testanything.org/>`_. The Linux Kernel largely uses TAP output for test
10 results. However, Kernel testing frameworks have special needs for test results
11 which don't align with the original TAP specification. Thus, a "Kernel TAP"
12 (KTAP) format is specified to extend and alter TAP to support these use-cases.
13 This specification describes the generally accepted format of KTAP as it is
14 currently used in the kernel.
15
16 KTAP test results describe a series of tests (which may be nested: i.e., test
17 can have subtests), each of which can contain both diagnostic data -- e.g., log
18 lines -- and a final result. The test structure and results are
19 machine-readable, whereas the diagnostic data is unstructured and is there to
20 aid human debugging.
21
22 KTAP output is built from four different types of lines:
23
24 - Version lines
25 - Plan lines
26 - Test case result lines
27 - Diagnostic lines
28
29 In general, valid KTAP output should also form valid TAP output, but some
30 information, in particular nested test results, may be lost. Also note that
31 there is a stagnant draft specification for TAP14, KTAP diverges from this in
32 a couple of places (notably the "Subtest" header), which are described where
33 relevant later in this document.
34
35 Version lines
36 -------------
37
38 All KTAP-formatted results begin with a "version line" which specifies which
39 version of the (K)TAP standard the result is compliant with.
40
41 For example:
42
43 - "KTAP version 1"
44 - "TAP version 13"
45 - "TAP version 14"
46
47 Note that, in KTAP, subtests also begin with a version line, which denotes the
48 start of the nested test results. This differs from TAP14, which uses a
49 separate "Subtest" line.
50
51 While, going forward, "KTAP version 1" should be used by compliant tests, it
52 is expected that most parsers and other tooling will accept the other versions
53 listed here for compatibility with existing tests and frameworks.
54
55 Plan lines
56 ----------
57
58 A test plan provides the number of tests (or subtests) in the KTAP output.
59
60 Plan lines must follow the format of "1..N" where N is the number of tests or subtests.
61 Plan lines follow version lines to indicate the number of nested tests.
62
63 While there are cases where the number of tests is not known in advance -- in
64 which case the test plan may be omitted -- it is strongly recommended one is
65 present where possible.
66
67 Test case result lines
68 ----------------------
69
70 Test case result lines indicate the final status of a test.
71 They are required and must have the format:
72
73 .. code-block:: none
74
75 <result> <number> [<description>][ # [<directive>] [<diagnostic data>]]
76
77 The result can be either "ok", which indicates the test case passed,
78 or "not ok", which indicates that the test case failed.
79
80 <number> represents the number of the test being performed. The first test must
81 have the number 1 and the number then must increase by 1 for each additional
82 subtest within the same test at the same nesting level.
83
84 The description is a description of the test, generally the name of
85 the test, and can be any string of characters other than # or a
86 newline. The description is optional, but recommended.
87
88 The directive and any diagnostic data is optional. If either are present, they
89 must follow a hash sign, "#".
90
91 A directive is a keyword that indicates a different outcome for a test other
92 than passed and failed. The directive is optional, and consists of a single
93 keyword preceding the diagnostic data. In the event that a parser encounters
94 a directive it doesn't support, it should fall back to the "ok" / "not ok"
95 result.
96
97 Currently accepted directives are:
98
99 - "SKIP", which indicates a test was skipped (note the result of the test case
100 result line can be either "ok" or "not ok" if the SKIP directive is used)
101 - "TODO", which indicates that a test is not expected to pass at the moment,
102 e.g. because the feature it is testing is known to be broken. While this
103 directive is inherited from TAP, its use in the kernel is discouraged.
104 - "XFAIL", which indicates that a test is expected to fail. This is similar
105 to "TODO", above, and is used by some kselftest tests.
106 - “TIMEOUT”, which indicates a test has timed out (note the result of the test
107 case result line should be “not ok” if the TIMEOUT directive is used)
108 - “ERROR”, which indicates that the execution of a test has failed due to a
109 specific error that is included in the diagnostic data. (note the result of
110 the test case result line should be “not ok” if the ERROR directive is used)
111
112 The diagnostic data is a plain-text field which contains any additional details
113 about why this result was produced. This is typically an error message for ERROR
114 or failed tests, or a description of missing dependencies for a SKIP result.
115
116 The diagnostic data field is optional, and results which have neither a
117 directive nor any diagnostic data do not need to include the "#" field
118 separator.
119
120 Example result lines include::
121
122 ok 1 test_case_name
123
124 The test "test_case_name" passed.
125
126 ::
127
128 not ok 1 test_case_name
129
130 The test "test_case_name" failed.
131
132 ::
133
134 ok 1 test # SKIP necessary dependency unavailable
135
136 The test "test" was SKIPPED with the diagnostic message "necessary dependency
137 unavailable".
138
139 ::
140
141 not ok 1 test # TIMEOUT 30 seconds
142
143 The test "test" timed out, with diagnostic data "30 seconds".
144
145 ::
146
147 ok 5 check return code # rcode=0
148
149 The test "check return code" passed, with additional diagnostic data “rcode=0”
150
151
152 Diagnostic lines
153 ----------------
154
155 If tests wish to output any further information, they should do so using
156 "diagnostic lines". Diagnostic lines are optional, freeform text, and are
157 often used to describe what is being tested and any intermediate results in
158 more detail than the final result and diagnostic data line provides.
159
160 Diagnostic lines are formatted as "# <diagnostic_description>", where the
161 description can be any string. Diagnostic lines can be anywhere in the test
162 output. As a rule, diagnostic lines regarding a test are directly before the
163 test result line for that test.
164
165 Note that most tools will treat unknown lines (see below) as diagnostic lines,
166 even if they do not start with a "#": this is to capture any other useful
167 kernel output which may help debug the test. It is nevertheless recommended
168 that tests always prefix any diagnostic output they have with a "#" character.
169
170 Unknown lines
171 -------------
172
173 There may be lines within KTAP output that do not follow the format of one of
174 the four formats for lines described above. This is allowed, however, they will
175 not influence the status of the tests.
176
177 This is an important difference from TAP. Kernel tests may print messages
178 to the system console or a log file. Both of these destinations may contain
179 messages either from unrelated kernel or userspace activity, or kernel
180 messages from non-test code that is invoked by the test. The kernel code
181 invoked by the test likely is not aware that a test is in progress and
182 thus can not print the message as a diagnostic message.
183
184 Nested tests
185 ------------
186
187 In KTAP, tests can be nested. This is done by having a test include within its
188 output an entire set of KTAP-formatted results. This can be used to categorize
189 and group related tests, or to split out different results from the same test.
190
191 The "parent" test's result should consist of all of its subtests' results,
192 starting with another KTAP version line and test plan, and end with the overall
193 result. If one of the subtests fail, for example, the parent test should also
194 fail.
195
196 Additionally, all lines in a subtest should be indented. One level of
197 indentation is two spaces: " ". The indentation should begin at the version
198 line and should end before the parent test's result line.
199
200 "Unknown lines" are not considered to be lines in a subtest and thus are
201 allowed to be either indented or not indented.
202
203 An example of a test with two nested subtests:
204
205 ::
206
207 KTAP version 1
208 1..1
209 KTAP version 1
210 1..2
211 ok 1 test_1
212 not ok 2 test_2
213 # example failed
214 not ok 1 example
215
216 An example format with multiple levels of nested testing:
217
218 ::
219
220 KTAP version 1
221 1..2
222 KTAP version 1
223 1..2
224 KTAP version 1
225 1..2
226 not ok 1 test_1
227 ok 2 test_2
228 not ok 1 test_3
229 ok 2 test_4 # SKIP
230 not ok 1 example_test_1
231 ok 2 example_test_2
232
233
234 Major differences between TAP and KTAP
235 --------------------------------------
236
237 ================================================== ========= ===============
238 Feature TAP KTAP
239 ================================================== ========= ===============
240 yaml and json in diagnosic message ok not recommended
241 TODO directive ok not recognized
242 allows an arbitrary number of tests to be nested no yes
243 "Unknown lines" are in category of "Anything else" yes no
244 "Unknown lines" are incorrect allowed
245 ================================================== ========= ===============
246
247 The TAP14 specification does permit nested tests, but instead of using another
248 nested version line, uses a line of the form
249 "Subtest: <name>" where <name> is the name of the parent test.
250
251 Example KTAP output
252 --------------------
253 ::
254
255 KTAP version 1
256 1..1
257 KTAP version 1
258 1..3
259 KTAP version 1
260 1..1
261 # test_1: initializing test_1
262 ok 1 test_1
263 ok 1 example_test_1
264 KTAP version 1
265 1..2
266 ok 1 test_1 # SKIP test_1 skipped
267 ok 2 test_2
268 ok 2 example_test_2
269 KTAP version 1
270 1..3
271 ok 1 test_1
272 # test_2: FAIL
273 not ok 2 test_2
274 ok 3 test_3 # SKIP test_3 skipped
275 not ok 3 example_test_3
276 not ok 1 main_test
277
278 This output defines the following hierarchy:
279
280 A single test called "main_test", which fails, and has three subtests:
281
282 - "example_test_1", which passes, and has one subtest:
283
284 - "test_1", which passes, and outputs the diagnostic message "test_1: initializing test_1"
285
286 - "example_test_2", which passes, and has two subtests:
287
288 - "test_1", which is skipped, with the explanation "test_1 skipped"
289 - "test_2", which passes
290
291 - "example_test_3", which fails, and has three subtests
292
293 - "test_1", which passes
294 - "test_2", which outputs the diagnostic line "test_2: FAIL", and fails.
295 - "test_3", which is skipped with the explanation "test_3 skipped"
296
297 Note that the individual subtests with the same names do not conflict, as they
298 are found in different parent tests. This output also exhibits some sensible
299 rules for "bubbling up" test results: a test fails if any of its subtests fail.
300 Skipped tests do not affect the result of the parent test (though it often
301 makes sense for a test to be marked skipped if _all_ of its subtests have been
302 skipped).
303
304 See also:
305 ---------
306
307 - The TAP specification:
308 https://testanything.org/tap-version-13-specification.html
309 - The (stagnant) TAP version 14 specification:
310 https://github.com/TestAnything/Specification/blob/tap-14-specification/specification.md
311 - The kselftest documentation:
312 Documentation/dev-tools/kselftest.rst
313 - The KUnit documentation:
314 Documentation/dev-tools/kunit/index.rst
315

3. 한국어 전문 번역

영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.

KTAP 개요와 출력 구성

1-34

SPDX 라이선스 식별자: GPL-2.0

Kernel Test Anything Protocol (KTAP), version 1

TAP, 즉 Test Anything Protocol은 여러 프로젝트가 테스트 결과를 표현하는 데 사용하는 형식입니다. 웹사이트와 명세는 https://testanything.org/ 에 있습니다. Linux kernel은 테스트 결과에 TAP 출력을 널리 사용하지만 kernel testing framework에는 원래 TAP 명세와 맞지 않는 특별한 요구가 있습니다. 이에 TAP를 확장하고 변경해 이러한 용례를 지원하는 Kernel TAP, 즉 KTAP 형식을 정의했습니다. 이 명세는 현재 커널에서 일반적으로 인정되고 사용되는 KTAP 형식을 설명합니다.

KTAP 테스트 결과는 일련의 테스트를 기술합니다. 테스트는 중첩되어 subtest를 가질 수 있으며, 각 테스트는 log line 같은 diagnostic data와 최종 결과를 모두 포함할 수 있습니다. 테스트 구조와 결과는 machine-readable이고 diagnostic data는 정형화되지 않은 사람의 디버깅을 위한 정보입니다.

KTAP 출력은 다음 네 종류의 line으로 구성됩니다.

Version line

Plan line

Test case result line

Diagnostic line

일반적으로 유효한 KTAP 출력은 유효한 TAP 출력이기도 해야 하지만 특히 중첩된 테스트 결과 같은 일부 정보는 손실될 수 있습니다. 정체된 TAP14 draft specification도 존재하지만 KTAP는 몇 군데, 특히 `Subtest` header에서 이 명세와 다르며 관련 차이는 뒤에서 설명합니다.

Version line과 plan line

35-66

Version line

KTAP 형식의 모든 결과는 해당 결과가 어느 (K)TAP 표준 version을 따르는지 지정하는 version line으로 시작합니다.

예: `KTAP version 1`

예: `TAP version 13`

예: `TAP version 14`

KTAP에서는 subtest도 version line으로 시작하며, 이 line이 중첩된 테스트 결과의 시작을 나타냅니다. 별도의 `Subtest` line을 사용하는 TAP14와 다른 점입니다.

앞으로 명세를 준수하는 테스트는 `KTAP version 1`을 사용해야 합니다. 다만 기존 테스트와 framework의 호환성을 위해 parser와 기타 tooling 대부분은 위에 나열한 다른 version도 받아들일 것으로 예상합니다.

Plan line

Test plan은 KTAP 출력에 포함된 test 또는 subtest 수를 제공합니다.

Plan line은 `1..N` 형식이어야 하며 N은 test 또는 subtest 수입니다. 중첩된 테스트 수를 알리기 위해 version line 다음에 plan line이 옵니다.

테스트 수를 미리 알 수 없어 test plan을 생략할 수 있는 경우도 있지만 가능한 곳에서는 plan을 넣기를 강하게 권장합니다.

Test case result line과 directive

67-151

Test case result line

Test case result line은 테스트의 최종 상태를 나타냅니다. 반드시 있어야 하며 다음 형식을 따라야 합니다.

<result> <number> [<description>][ # [<directive>] [<diagnostic data>]]
KTAP 결과 line 구성
필드필수 여부의미
result필수ok 또는 not ok
number필수같은 nesting level에서 1부터 순차 증가
description선택 권장#와 newline을 제외한 테스트 설명
directive선택SKIP, TODO, XFAIL, TIMEOUT, ERROR
diagnostic data선택결과 이유나 추가 세부 정보

필수 결과와 번호 뒤에 선택적 설명, directive, 진단 정보를 붙이는 문법입니다.

Result는 test case가 성공했음을 나타내는 `ok` 또는 실패했음을 나타내는 `not ok`입니다.

`number`는 수행하는 테스트 번호입니다. 첫 테스트는 1이어야 하며 같은 테스트와 같은 nesting level의 subtest가 추가될 때마다 1씩 증가해야 합니다.

Description은 일반적으로 테스트 이름인 설명입니다. `#` 또는 newline을 제외한 임의 문자열을 사용할 수 있습니다. 선택 사항이지만 넣기를 권장합니다.

Directive와 diagnostic data는 선택 사항입니다. 둘 중 하나라도 있으면 hash sign `#` 뒤에 와야 합니다.

Directive는 pass와 fail 외의 다른 결과를 나타내는 선택적 keyword이며 diagnostic data보다 앞에 옵니다. Parser가 지원하지 않는 directive를 만나면 `ok` 또는 `not ok` 결과로 돌아가 해석해야 합니다.

현재 허용되는 directive는 다음과 같습니다.

`SKIP`: 테스트를 건너뛰었음을 나타냅니다. SKIP을 사용할 때 result line은 `ok` 또는 `not ok` 모두 가능합니다.

`TODO`: 현재 테스트가 성공할 것으로 예상하지 않음을 나타냅니다. 예를 들어 검사 대상 기능이 고장 난 것으로 알려진 경우입니다. TAP에서 물려받은 directive지만 kernel에서는 사용을 권장하지 않습니다.

`XFAIL`: 테스트가 실패할 것으로 예상함을 나타냅니다. 위의 TODO와 비슷하며 일부 kselftest가 사용합니다.

`TIMEOUT`: 테스트가 timeout되었음을 나타냅니다. 이 directive를 사용할 때 result line은 `not ok`여야 합니다.

`ERROR`: diagnostic data에 포함된 특정 오류 때문에 테스트 실행이 실패했음을 나타냅니다. 이 directive를 사용할 때 result line은 `not ok`여야 합니다.

Diagnostic data는 결과가 나온 이유에 대한 추가 세부 정보를 담는 plain-text field입니다. 보통 ERROR나 실패한 테스트의 error message 또는 SKIP 결과에서 빠진 dependency에 대한 설명입니다.

Diagnostic data field는 선택 사항입니다. Directive와 diagnostic data가 모두 없는 결과는 `#` field separator를 넣지 않아도 됩니다.

다음은 result line 예입니다.

ok 1 test_case_name

`test_case_name` 테스트가 성공했습니다.

not ok 1 test_case_name

`test_case_name` 테스트가 실패했습니다.

ok 1 test # SKIP necessary dependency unavailable

`test`를 건너뛰었고 diagnostic message는 `necessary dependency unavailable`입니다.

not ok 1 test # TIMEOUT 30 seconds

`test`가 timeout되었고 diagnostic data는 `30 seconds`입니다.

ok 5 check return code # rcode=0

`check return code` 테스트가 성공했으며 추가 diagnostic data는 `rcode=0`입니다.

Diagnostic line과 unknown line

152-183

Diagnostic line

테스트가 추가 정보를 출력하려면 diagnostic line을 사용해야 합니다. Diagnostic line은 선택적인 자유 형식 text이며 최종 result와 diagnostic data line보다 더 자세하게 검사 대상과 중간 결과를 설명할 때 자주 사용합니다.

Diagnostic line 형식은 `# <diagnostic_description>`이며 description은 임의 문자열일 수 있습니다. 출력 어디에나 둘 수 있지만 일반적으로 한 테스트에 대한 diagnostic line은 그 테스트의 result line 바로 앞에 둡니다.

대부분의 tool은 아래에서 설명하는 unknown line이 `#`로 시작하지 않더라도 diagnostic line으로 취급합니다. 테스트 디버깅에 도움이 되는 다른 kernel 출력을 포착하기 위해서입니다. 그래도 테스트가 내보내는 모든 diagnostic output에는 항상 `#` 문자를 붙이기를 권장합니다.

Unknown line

KTAP 출력에는 앞서 설명한 네 형식 중 어느 것에도 맞지 않는 line이 있을 수 있습니다. 이를 허용하지만 테스트 상태에는 영향을 주지 않습니다.

이는 TAP와의 중요한 차이입니다. Kernel 테스트는 system console 또는 log file에 message를 출력할 수 있습니다. 두 위치에는 관계없는 kernel 또는 userspace activity의 message나 테스트가 호출한 비테스트 kernel code의 message가 섞일 수 있습니다. 호출된 kernel code는 테스트가 진행 중임을 모를 가능성이 크므로 message를 diagnostic message 형식으로 출력할 수 없습니다.

중첩 테스트와 들여쓰기

184-233

중첩 테스트

KTAP에서는 테스트를 중첩할 수 있습니다. 한 테스트의 출력 안에 KTAP 형식의 전체 결과 집합을 포함하는 방식입니다. 관련 테스트를 분류하고 묶거나 같은 테스트에서 나온 서로 다른 결과를 나누는 데 사용할 수 있습니다.

Parent test의 결과는 다른 KTAP version line과 test plan으로 시작하는 모든 subtest 결과를 포함하고 마지막에 전체 결과로 끝나야 합니다. 예를 들어 subtest 하나가 실패하면 parent test도 실패해야 합니다.

또한 subtest의 모든 line은 들여써야 합니다. 들여쓰기 한 level은 두 칸 ` `입니다. Version line부터 들여쓰기하고 parent test result line 앞에서 끝내야 합니다.

Unknown line은 subtest의 line으로 간주하지 않으므로 들여쓰거나 들여쓰지 않아도 됩니다.

두 subtest를 가진 테스트의 예입니다.

KTAP version 1
1..1
  KTAP version 1
  1..2
  ok 1 test_1
  not ok 2 test_2
# example failed
not ok 1 example

여러 level로 중첩된 테스트 형식의 예입니다.

KTAP version 1
1..2
  KTAP version 1
  1..2
    KTAP version 1
    1..2
    not ok 1 test_1
    ok 2 test_2
  not ok 1 test_3
  ok 2 test_4 # SKIP
not ok 1 example_test_1
ok 2 example_test_2
KTAP 중첩 결과 구조
Parent version + plan최상위 test 수 선언
들여쓴 child version + plansubtest 범위 시작
Child resultok 또는 not ok와 진단 출력
Parent resultchild 실패를 반영한 전체 결과

각 level이 독립적인 version과 plan을 가진 뒤 결과가 parent로 올라가는 구조입니다.

TAP와 KTAP의 주요 차이

234-250

TAP와 KTAP의 주요 차이

==================================================   =========  ===============
Feature                                              TAP        KTAP
==================================================   =========  ===============
yaml and json in diagnosic message                   ok         not recommended
TODO directive                                       ok         not recognized
allows an arbitrary number of tests to be nested     no         yes
"Unknown lines" are in category of "Anything else"   yes        no
"Unknown lines" are                                  incorrect  allowed
==================================================   =========  ===============
TAP와 KTAP 비교
기능TAPKTAP
Diagnostic message의 YAML/JSON허용권장하지 않음
TODO directive허용인식하지 않음
임의 깊이 테스트 중첩불가가능
Unknown line 분류Anything else별도 취급
Unknown line 유효성잘못된 출력허용

원문의 표를 한국어 구조화 표로 다시 정리했습니다.

TAP14 명세도 중첩 테스트를 허용하지만 중첩된 version line 대신 `Subtest: <name>` 형식의 line을 사용합니다. 여기서 `<name>`은 parent test 이름입니다.

전체 KTAP 예제와 결과 전파

251-303

KTAP 출력 예

KTAP version 1
1..1
  KTAP version 1
  1..3
    KTAP version 1
    1..1
    # test_1: initializing test_1
    ok 1 test_1
  ok 1 example_test_1
    KTAP version 1
    1..2
    ok 1 test_1 # SKIP test_1 skipped
    ok 2 test_2
  ok 2 example_test_2
    KTAP version 1
    1..3
    ok 1 test_1
    # test_2: FAIL
    not ok 2 test_2
    ok 3 test_3 # SKIP test_3 skipped
  not ok 3 example_test_3
not ok 1 main_test

이 출력은 다음 hierarchy를 정의합니다.

`main_test`라는 단일 테스트가 실패하며 세 개의 subtest를 가집니다.

`example_test_1`은 성공하며 한 subtest를 가집니다. `test_1`은 성공하고 `test_1: initializing test_1` diagnostic message를 출력합니다.

`example_test_2`는 성공하며 두 subtest를 가집니다. 첫 번째 `test_1`은 `test_1 skipped` 설명과 함께 skip되고, `test_2`는 성공합니다.

`example_test_3`은 실패하며 세 subtest를 가집니다. `test_1`은 성공하고, `test_2`는 `test_2: FAIL` diagnostic line을 출력한 뒤 실패하며, `test_3`은 `test_3 skipped` 설명과 함께 skip됩니다.

이름이 같은 개별 subtest는 서로 다른 parent test에 있으므로 충돌하지 않습니다. 이 출력은 결과를 위로 전파하는 합리적인 규칙도 보여 줍니다. Subtest 하나라도 실패하면 parent test가 실패합니다. Skip된 테스트는 parent 결과에 영향을 주지 않지만 모든 subtest가 skip되었다면 parent도 skip으로 표시하는 것이 타당한 경우가 많습니다.

관련 명세와 문서

304-314

관련 자료

TAP 명세: https://testanything.org/tap-version-13-specification.html

정체된 TAP version 14 명세: https://github.com/TestAnything/Specification/blob/tap-14-specification/specification.md

Kselftest 문서: `Documentation/dev-tools/kselftest.rst`

KUnit 문서: `Documentation/dev-tools/kunit/index.rst`