1.. SPDX-License-Identifier: GPL-2.0
2
3Writing Tests
4=============
5
6Test Cases
7----------
8
9The fundamental unit in KUnit is the test case. A test case is a function with
10the signature ``void (*)(struct kunit *test)``. It calls the function under test
11and then sets *expectations* for what should happen. For example:
12
13.. code-block:: c
14
15	void example_test_success(struct kunit *test)
16	{
17	}
18
19	void example_test_failure(struct kunit *test)
20	{
21		KUNIT_FAIL(test, "This test never passes.");
22	}
23
24In the above example, ``example_test_success`` always passes because it does
25nothing; no expectations are set, and therefore all expectations pass. On the
26other hand ``example_test_failure`` always fails because it calls ``KUNIT_FAIL``,
27which is a special expectation that logs a message and causes the test case to
28fail.
29
30Expectations
31~~~~~~~~~~~~
32An *expectation* specifies that we expect a piece of code to do something in a
33test. An expectation is called like a function. A test is made by setting
34expectations about the behavior of a piece of code under test. When one or more
35expectations fail, the test case fails and information about the failure is
36logged. For example:
37
38.. code-block:: c
39
40	void add_test_basic(struct kunit *test)
41	{
42		KUNIT_EXPECT_EQ(test, 1, add(1, 0));
43		KUNIT_EXPECT_EQ(test, 2, add(1, 1));
44	}
45
46In the above example, ``add_test_basic`` makes a number of assertions about the
47behavior of a function called ``add``. The first parameter is always of type
48``struct kunit *``, which contains information about the current test context.
49The second parameter, in this case, is what the value is expected to be. The
50last value is what the value actually is. If ``add`` passes all of these
51expectations, the test case, ``add_test_basic`` will pass; if any one of these
52expectations fails, the test case will fail.
53
54A test case *fails* when any expectation is violated; however, the test will
55continue to run, and try other expectations until the test case ends or is
56otherwise terminated. This is as opposed to *assertions* which are discussed
57later.
58
59To learn about more KUnit expectations, see Documentation/dev-tools/kunit/api/test.rst.
60
61.. note::
62   A single test case should be short, easy to understand, and focused on a
63   single behavior.
64
65For example, if we want to rigorously test the ``add`` function above, create
66additional tests cases which would test each property that an ``add`` function
67should have as shown below:
68
69.. code-block:: c
70
71	void add_test_basic(struct kunit *test)
72	{
73		KUNIT_EXPECT_EQ(test, 1, add(1, 0));
74		KUNIT_EXPECT_EQ(test, 2, add(1, 1));
75	}
76
77	void add_test_negative(struct kunit *test)
78	{
79		KUNIT_EXPECT_EQ(test, 0, add(-1, 1));
80	}
81
82	void add_test_max(struct kunit *test)
83	{
84		KUNIT_EXPECT_EQ(test, INT_MAX, add(0, INT_MAX));
85		KUNIT_EXPECT_EQ(test, -1, add(INT_MAX, INT_MIN));
86	}
87
88	void add_test_overflow(struct kunit *test)
89	{
90		KUNIT_EXPECT_EQ(test, INT_MIN, add(INT_MAX, 1));
91	}
92
93Assertions
94~~~~~~~~~~
95
96An assertion is like an expectation, except that the assertion immediately
97terminates the test case if the condition is not satisfied. For example:
98
99.. code-block:: c
100
101	static void test_sort(struct kunit *test)
102	{
103		int *a, i, r = 1;
104		a = kunit_kmalloc_array(test, TEST_LEN, sizeof(*a), GFP_KERNEL);
105		KUNIT_ASSERT_NOT_ERR_OR_NULL(test, a);
106		for (i = 0; i < TEST_LEN; i++) {
107			r = (r * 725861) % 6599;
108			a[i] = r;
109		}
110		sort(a, TEST_LEN, sizeof(*a), cmpint, NULL);
111		for (i = 0; i < TEST_LEN-1; i++)
112			KUNIT_EXPECT_LE(test, a[i], a[i + 1]);
113	}
114
115In this example, the method under test should return pointer to a value. If the
116pointer returns null or an errno, we want to stop the test since the following
117expectation could crash the test case. `ASSERT_NOT_ERR_OR_NULL(...)` allows us
118to bail out of the test case if the appropriate conditions are not satisfied to
119complete the test.
120
121Test Suites
122~~~~~~~~~~~
123
124We need many test cases covering all the unit's behaviors. It is common to have
125many similar tests. In order to reduce duplication in these closely related
126tests, most unit testing frameworks (including KUnit) provide the concept of a
127*test suite*. A test suite is a collection of test cases for a unit of code
128with optional setup and teardown functions that run before/after the whole
129suite and/or every test case. For example:
130
131.. code-block:: c
132
133	static struct kunit_case example_test_cases[] = {
134		KUNIT_CASE(example_test_foo),
135		KUNIT_CASE(example_test_bar),
136		KUNIT_CASE(example_test_baz),
137		{}
138	};
139
140	static struct kunit_suite example_test_suite = {
141		.name = "example",
142		.init = example_test_init,
143		.exit = example_test_exit,
144		.suite_init = example_suite_init,
145		.suite_exit = example_suite_exit,
146		.test_cases = example_test_cases,
147	};
148	kunit_test_suite(example_test_suite);
149
150In the above example, the test suite ``example_test_suite`` would first run
151``example_suite_init``, then run the test cases ``example_test_foo``,
152``example_test_bar``, and ``example_test_baz``. Each would have
153``example_test_init`` called immediately before it and ``example_test_exit``
154called immediately after it. Finally, ``example_suite_exit`` would be called
155after everything else. ``kunit_test_suite(example_test_suite)`` registers the
156test suite with the KUnit test framework.
157
158.. note::
159   A test case will only run if it is associated with a test suite.
160
161``kunit_test_suite(...)`` is a macro which tells the linker to put the
162specified test suite in a special linker section so that it can be run by KUnit
163either after ``late_init``, or when the test module is loaded (if the test was
164built as a module).
165
166For more information, see Documentation/dev-tools/kunit/api/test.rst.
167
168Writing Tests For Other Architectures
169-------------------------------------
170
171It is better to write tests that run on UML to tests that only run under a
172particular architecture. It is better to write tests that run under QEMU or
173another easy to obtain (and monetarily free) software environment to a specific
174piece of hardware.
175
176Nevertheless, there are still valid reasons to write a test that is architecture
177or hardware specific. For example, we might want to test code that really
178belongs in ``arch/some-arch/*``. Even so, try to write the test so that it does
179not depend on physical hardware. Some of our test cases may not need hardware,
180only few tests actually require the hardware to test it. When hardware is not
181available, instead of disabling tests, we can skip them.
182
183Now that we have narrowed down exactly what bits are hardware specific, the
184actual procedure for writing and running the tests is same as writing normal
185KUnit tests.
186
187.. important::
188   We may have to reset hardware state. If this is not possible, we may only
189   be able to run one test case per invocation.
190
191.. TODO(brendanhiggins@google.com): Add an actual example of an architecture-
192   dependent KUnit test.
193
194Common Patterns
195===============
196
197Isolating Behavior
198------------------
199
200Unit testing limits the amount of code under test to a single unit. It controls
201what code gets run when the unit under test calls a function. Where a function
202is exposed as part of an API such that the definition of that function can be
203changed without affecting the rest of the code base. In the kernel, this comes
204from two constructs: classes, which are structs that contain function pointers
205provided by the implementer, and architecture-specific functions, which have
206definitions selected at compile time.
207
208Classes
209~~~~~~~
210
211Classes are not a construct that is built into the C programming language;
212however, it is an easily derived concept. Accordingly, in most cases, every
213project that does not use a standardized object oriented library (like GNOME's
214GObject) has their own slightly different way of doing object oriented
215programming; the Linux kernel is no exception.
216
217The central concept in kernel object oriented programming is the class. In the
218kernel, a *class* is a struct that contains function pointers. This creates a
219contract between *implementers* and *users* since it forces them to use the
220same function signature without having to call the function directly. To be a
221class, the function pointers must specify that a pointer to the class, known as
222a *class handle*, be one of the parameters. Thus the member functions (also
223known as *methods*) have access to member variables (also known as *fields*)
224allowing the same implementation to have multiple *instances*.
225
226A class can be *overridden* by *child classes* by embedding the *parent class*
227in the child class. Then when the child class *method* is called, the child
228implementation knows that the pointer passed to it is of a parent contained
229within the child. Thus, the child can compute the pointer to itself because the
230pointer to the parent is always a fixed offset from the pointer to the child.
231This offset is the offset of the parent contained in the child struct. For
232example:
233
234.. code-block:: c
235
236	struct shape {
237		int (*area)(struct shape *this);
238	};
239
240	struct rectangle {
241		struct shape parent;
242		int length;
243		int width;
244	};
245
246	int rectangle_area(struct shape *this)
247	{
248		struct rectangle *self = container_of(this, struct rectangle, parent);
249
250		return self->length * self->width;
251	};
252
253	void rectangle_new(struct rectangle *self, int length, int width)
254	{
255		self->parent.area = rectangle_area;
256		self->length = length;
257		self->width = width;
258	}
259
260In this example, computing the pointer to the child from the pointer to the
261parent is done by ``container_of``.
262
263Faking Classes
264~~~~~~~~~~~~~~
265
266In order to unit test a piece of code that calls a method in a class, the
267behavior of the method must be controllable, otherwise the test ceases to be a
268unit test and becomes an integration test.
269
270A fake class implements a piece of code that is different than what runs in a
271production instance, but behaves identical from the standpoint of the callers.
272This is done to replace a dependency that is hard to deal with, or is slow. For
273example, implementing a fake EEPROM that stores the "contents" in an
274internal buffer. Assume we have a class that represents an EEPROM:
275
276.. code-block:: c
277
278	struct eeprom {
279		ssize_t (*read)(struct eeprom *this, size_t offset, char *buffer, size_t count);
280		ssize_t (*write)(struct eeprom *this, size_t offset, const char *buffer, size_t count);
281	};
282
283And we want to test code that buffers writes to the EEPROM:
284
285.. code-block:: c
286
287	struct eeprom_buffer {
288		ssize_t (*write)(struct eeprom_buffer *this, const char *buffer, size_t count);
289		int flush(struct eeprom_buffer *this);
290		size_t flush_count; /* Flushes when buffer exceeds flush_count. */
291	};
292
293	struct eeprom_buffer *new_eeprom_buffer(struct eeprom *eeprom);
294	void destroy_eeprom_buffer(struct eeprom *eeprom);
295
296We can test this code by *faking out* the underlying EEPROM:
297
298.. code-block:: c
299
300	struct fake_eeprom {
301		struct eeprom parent;
302		char contents[FAKE_EEPROM_CONTENTS_SIZE];
303	};
304
305	ssize_t fake_eeprom_read(struct eeprom *parent, size_t offset, char *buffer, size_t count)
306	{
307		struct fake_eeprom *this = container_of(parent, struct fake_eeprom, parent);
308
309		count = min(count, FAKE_EEPROM_CONTENTS_SIZE - offset);
310		memcpy(buffer, this->contents + offset, count);
311
312		return count;
313	}
314
315	ssize_t fake_eeprom_write(struct eeprom *parent, size_t offset, const char *buffer, size_t count)
316	{
317		struct fake_eeprom *this = container_of(parent, struct fake_eeprom, parent);
318
319		count = min(count, FAKE_EEPROM_CONTENTS_SIZE - offset);
320		memcpy(this->contents + offset, buffer, count);
321
322		return count;
323	}
324
325	void fake_eeprom_init(struct fake_eeprom *this)
326	{
327		this->parent.read = fake_eeprom_read;
328		this->parent.write = fake_eeprom_write;
329		memset(this->contents, 0, FAKE_EEPROM_CONTENTS_SIZE);
330	}
331
332We can now use it to test ``struct eeprom_buffer``:
333
334.. code-block:: c
335
336	struct eeprom_buffer_test {
337		struct fake_eeprom *fake_eeprom;
338		struct eeprom_buffer *eeprom_buffer;
339	};
340
341	static void eeprom_buffer_test_does_not_write_until_flush(struct kunit *test)
342	{
343		struct eeprom_buffer_test *ctx = test->priv;
344		struct eeprom_buffer *eeprom_buffer = ctx->eeprom_buffer;
345		struct fake_eeprom *fake_eeprom = ctx->fake_eeprom;
346		char buffer[] = {0xff};
347
348		eeprom_buffer->flush_count = SIZE_MAX;
349
350		eeprom_buffer->write(eeprom_buffer, buffer, 1);
351		KUNIT_EXPECT_EQ(test, fake_eeprom->contents[0], 0);
352
353		eeprom_buffer->write(eeprom_buffer, buffer, 1);
354		KUNIT_EXPECT_EQ(test, fake_eeprom->contents[1], 0);
355
356		eeprom_buffer->flush(eeprom_buffer);
357		KUNIT_EXPECT_EQ(test, fake_eeprom->contents[0], 0xff);
358		KUNIT_EXPECT_EQ(test, fake_eeprom->contents[1], 0xff);
359	}
360
361	static void eeprom_buffer_test_flushes_after_flush_count_met(struct kunit *test)
362	{
363		struct eeprom_buffer_test *ctx = test->priv;
364		struct eeprom_buffer *eeprom_buffer = ctx->eeprom_buffer;
365		struct fake_eeprom *fake_eeprom = ctx->fake_eeprom;
366		char buffer[] = {0xff};
367
368		eeprom_buffer->flush_count = 2;
369
370		eeprom_buffer->write(eeprom_buffer, buffer, 1);
371		KUNIT_EXPECT_EQ(test, fake_eeprom->contents[0], 0);
372
373		eeprom_buffer->write(eeprom_buffer, buffer, 1);
374		KUNIT_EXPECT_EQ(test, fake_eeprom->contents[0], 0xff);
375		KUNIT_EXPECT_EQ(test, fake_eeprom->contents[1], 0xff);
376	}
377
378	static void eeprom_buffer_test_flushes_increments_of_flush_count(struct kunit *test)
379	{
380		struct eeprom_buffer_test *ctx = test->priv;
381		struct eeprom_buffer *eeprom_buffer = ctx->eeprom_buffer;
382		struct fake_eeprom *fake_eeprom = ctx->fake_eeprom;
383		char buffer[] = {0xff, 0xff};
384
385		eeprom_buffer->flush_count = 2;
386
387		eeprom_buffer->write(eeprom_buffer, buffer, 1);
388		KUNIT_EXPECT_EQ(test, fake_eeprom->contents[0], 0);
389
390		eeprom_buffer->write(eeprom_buffer, buffer, 2);
391		KUNIT_EXPECT_EQ(test, fake_eeprom->contents[0], 0xff);
392		KUNIT_EXPECT_EQ(test, fake_eeprom->contents[1], 0xff);
393		/* Should have only flushed the first two bytes. */
394		KUNIT_EXPECT_EQ(test, fake_eeprom->contents[2], 0);
395	}
396
397	static int eeprom_buffer_test_init(struct kunit *test)
398	{
399		struct eeprom_buffer_test *ctx;
400
401		ctx = kunit_kzalloc(test, sizeof(*ctx), GFP_KERNEL);
402		KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ctx);
403
404		ctx->fake_eeprom = kunit_kzalloc(test, sizeof(*ctx->fake_eeprom), GFP_KERNEL);
405		KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ctx->fake_eeprom);
406		fake_eeprom_init(ctx->fake_eeprom);
407
408		ctx->eeprom_buffer = new_eeprom_buffer(&ctx->fake_eeprom->parent);
409		KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ctx->eeprom_buffer);
410
411		test->priv = ctx;
412
413		return 0;
414	}
415
416	static void eeprom_buffer_test_exit(struct kunit *test)
417	{
418		struct eeprom_buffer_test *ctx = test->priv;
419
420		destroy_eeprom_buffer(ctx->eeprom_buffer);
421	}
422
423Testing Against Multiple Inputs
424-------------------------------
425
426Testing just a few inputs is not enough to ensure that the code works correctly,
427for example: testing a hash function.
428
429We can write a helper macro or function. The function is called for each input.
430For example, to test ``sha1sum(1)``, we can write:
431
432.. code-block:: c
433
434	#define TEST_SHA1(in, want) \
435		sha1sum(in, out); \
436		KUNIT_EXPECT_STREQ_MSG(test, out, want, "sha1sum(%s)", in);
437
438	char out[40];
439	TEST_SHA1("hello world",  "2aae6c35c94fcfb415dbe95f408b9ce91ee846ed");
440	TEST_SHA1("hello world!", "430ce34d020724ed75a196dfc2ad67c77772d169");
441
442Note the use of the ``_MSG`` version of ``KUNIT_EXPECT_STREQ`` to print a more
443detailed error and make the assertions clearer within the helper macros.
444
445The ``_MSG`` variants are useful when the same expectation is called multiple
446times (in a loop or helper function) and thus the line number is not enough to
447identify what failed, as shown below.
448
449In complicated cases, we recommend using a *table-driven test* compared to the
450helper macro variation, for example:
451
452.. code-block:: c
453
454	int i;
455	char out[40];
456
457	struct sha1_test_case {
458		const char *str;
459		const char *sha1;
460	};
461
462	struct sha1_test_case cases[] = {
463		{
464			.str = "hello world",
465			.sha1 = "2aae6c35c94fcfb415dbe95f408b9ce91ee846ed",
466		},
467		{
468			.str = "hello world!",
469			.sha1 = "430ce34d020724ed75a196dfc2ad67c77772d169",
470		},
471	};
472	for (i = 0; i < ARRAY_SIZE(cases); ++i) {
473		sha1sum(cases[i].str, out);
474		KUNIT_EXPECT_STREQ_MSG(test, out, cases[i].sha1,
475		                      "sha1sum(%s)", cases[i].str);
476	}
477
478
479There is more boilerplate code involved, but it can:
480
481* be more readable when there are multiple inputs/outputs (due to field names).
482
483  * For example, see ``fs/ext4/inode-test.c``.
484
485* reduce duplication if test cases are shared across multiple tests.
486
487  * For example: if we want to test ``sha256sum``, we could add a ``sha256``
488    field and reuse ``cases``.
489
490* be converted to a "parameterized test".
491
492Parameterized Testing
493~~~~~~~~~~~~~~~~~~~~~
494
495The table-driven testing pattern is common enough that KUnit has special
496support for it.
497
498By reusing the same ``cases`` array from above, we can write the test as a
499"parameterized test" with the following.
500
501.. code-block:: c
502
503	// This is copy-pasted from above.
504	struct sha1_test_case {
505		const char *str;
506		const char *sha1;
507	};
508	const struct sha1_test_case cases[] = {
509		{
510			.str = "hello world",
511			.sha1 = "2aae6c35c94fcfb415dbe95f408b9ce91ee846ed",
512		},
513		{
514			.str = "hello world!",
515			.sha1 = "430ce34d020724ed75a196dfc2ad67c77772d169",
516		},
517	};
518
519	// Need a helper function to generate a name for each test case.
520	static void case_to_desc(const struct sha1_test_case *t, char *desc)
521	{
522		strcpy(desc, t->str);
523	}
524	// Creates `sha1_gen_params()` to iterate over `cases`.
525	KUNIT_ARRAY_PARAM(sha1, cases, case_to_desc);
526
527	// Looks no different from a normal test.
528	static void sha1_test(struct kunit *test)
529	{
530		// This function can just contain the body of the for-loop.
531		// The former `cases[i]` is accessible under test->param_value.
532		char out[40];
533		struct sha1_test_case *test_param = (struct sha1_test_case *)(test->param_value);
534
535		sha1sum(test_param->str, out);
536		KUNIT_EXPECT_STREQ_MSG(test, out, test_param->sha1,
537				      "sha1sum(%s)", test_param->str);
538	}
539
540	// Instead of KUNIT_CASE, we use KUNIT_CASE_PARAM and pass in the
541	// function declared by KUNIT_ARRAY_PARAM.
542	static struct kunit_case sha1_test_cases[] = {
543		KUNIT_CASE_PARAM(sha1_test, sha1_gen_params),
544		{}
545	};
546
547.. _kunit-on-non-uml:
548
549Exiting Early on Failed Expectations
550------------------------------------
551
552We can use ``KUNIT_EXPECT_EQ`` to mark the test as failed and continue
553execution.  In some cases, it is unsafe to continue. We can use the
554``KUNIT_ASSERT`` variant to exit on failure.
555
556.. code-block:: c
557
558	void example_test_user_alloc_function(struct kunit *test)
559	{
560		void *object = alloc_some_object_for_me();
561
562		/* Make sure we got a valid pointer back. */
563		KUNIT_ASSERT_NOT_ERR_OR_NULL(test, object);
564		do_something_with_object(object);
565	}
566
567Allocating Memory
568-----------------
569
570Where you might use ``kzalloc``, you can instead use ``kunit_kzalloc`` as KUnit
571will then ensure that the memory is freed once the test completes.
572
573This is useful because it lets us use the ``KUNIT_ASSERT_EQ`` macros to exit
574early from a test without having to worry about remembering to call ``kfree``.
575For example:
576
577.. code-block:: c
578
579	void example_test_allocation(struct kunit *test)
580	{
581		char *buffer = kunit_kzalloc(test, 16, GFP_KERNEL);
582		/* Ensure allocation succeeded. */
583		KUNIT_ASSERT_NOT_ERR_OR_NULL(test, buffer);
584
585		KUNIT_ASSERT_STREQ(test, buffer, "");
586	}
587
588
589Testing Static Functions
590------------------------
591
592If we do not want to expose functions or variables for testing, one option is to
593conditionally ``#include`` the test file at the end of your .c file. For
594example:
595
596.. code-block:: c
597
598	/* In my_file.c */
599
600	static int do_interesting_thing();
601
602	#ifdef CONFIG_MY_KUNIT_TEST
603	#include "my_kunit_test.c"
604	#endif
605
606Injecting Test-Only Code
607------------------------
608
609Similar to as shown above, we can add test-specific logic. For example:
610
611.. code-block:: c
612
613	/* In my_file.h */
614
615	#ifdef CONFIG_MY_KUNIT_TEST
616	/* Defined in my_kunit_test.c */
617	void test_only_hook(void);
618	#else
619	void test_only_hook(void) { }
620	#endif
621
622This test-only code can be made more useful by accessing the current ``kunit_test``
623as shown in next section: *Accessing The Current Test*.
624
625Accessing The Current Test
626--------------------------
627
628In some cases, we need to call test-only code from outside the test file.
629For example, see example in section *Injecting Test-Only Code* or if
630we are providing a fake implementation of an ops struct. Using
631``kunit_test`` field in ``task_struct``, we can access it via
632``current->kunit_test``.
633
634The example below includes how to implement "mocking":
635
636.. code-block:: c
637
638	#include <linux/sched.h> /* for current */
639
640	struct test_data {
641		int foo_result;
642		int want_foo_called_with;
643	};
644
645	static int fake_foo(int arg)
646	{
647		struct kunit *test = current->kunit_test;
648		struct test_data *test_data = test->priv;
649
650		KUNIT_EXPECT_EQ(test, test_data->want_foo_called_with, arg);
651		return test_data->foo_result;
652	}
653
654	static void example_simple_test(struct kunit *test)
655	{
656		/* Assume priv (private, a member used to pass test data from
657		 * the init function) is allocated in the suite's .init */
658		struct test_data *test_data = test->priv;
659
660		test_data->foo_result = 42;
661		test_data->want_foo_called_with = 1;
662
663		/* In a real test, we'd probably pass a pointer to fake_foo somewhere
664		 * like an ops struct, etc. instead of calling it directly. */
665		KUNIT_EXPECT_EQ(test, fake_foo(1), 42);
666	}
667
668In this example, we are using the ``priv`` member of ``struct kunit`` as a way
669of passing data to the test from the init function. In general ``priv`` is
670pointer that can be used for any user data. This is preferred over static
671variables, as it avoids concurrency issues.
672
673Had we wanted something more flexible, we could have used a named ``kunit_resource``.
674Each test can have multiple resources which have string names providing the same
675flexibility as a ``priv`` member, but also, for example, allowing helper
676functions to create resources without conflicting with each other. It is also
677possible to define a clean up function for each resource, making it easy to
678avoid resource leaks. For more information, see Documentation/dev-tools/kunit/api/test.rst.
679
680Failing The Current Test
681------------------------
682
683If we want to fail the current test, we can use ``kunit_fail_current_test(fmt, args...)``
684which is defined in ``<kunit/test-bug.h>`` and does not require pulling in ``<kunit/test.h>``.
685For example, we have an option to enable some extra debug checks on some data
686structures as shown below:
687
688.. code-block:: c
689
690	#include <kunit/test-bug.h>
691
692	#ifdef CONFIG_EXTRA_DEBUG_CHECKS
693	static void validate_my_data(struct data *data)
694	{
695		if (is_valid(data))
696			return;
697
698		kunit_fail_current_test("data %p is invalid", data);
699
700		/* Normal, non-KUnit, error reporting code here. */
701	}
702	#else
703	static void my_debug_function(void) { }
704	#endif
705
706