.. SPDX-License-Identifier: GPL-2.0 ===========Using KUnit=========== The purpose of this document is to describe what KUnit is, how it works, how itis intended to be used, and all the concepts and terminology that are needed tounderstand it. This guide assumes a working knowledge of the Linux kernel andsome basic knowledge of testing. For a high level introduction to KUnit, including setting up KUnit for yourproject, see :doc:`start`. Organization of this document============================= This document is organized into two main sections: Testing and Common Patterns.The first covers what unit tests are and how to use KUnit to write them. Thesecond covers common testing patterns, e.g. how to isolate code and make itpossible to unit test code that was otherwise un-unit-testable. Testing======= What is KUnit?-------------- "K" is short for "kernel" so "KUnit" is the "(Linux) Kernel Unit TestingFramework." KUnit is intended first and foremost for writing unit tests; it isgeneral enough that it can be used to write integration tests; however, this isa secondary goal. KUnit has no ambition of being the only testing framework forthe kernel; for example, it does not intend to be an end-to-end testingframework. What is Unit Testing?--------------------- A `unit test <https://martinfowler.com/bliki/UnitTest.html>`_ is a test thattests code at the smallest possible scope, a *unit* of code. In the Cprogramming language that's a function. Unit tests should be written for all the publicly exposed functions in acompilation unit; so that is all the functions that are exported in either a*class* (defined below) or all functions which are **not** static. Writing Tests------------- Test Cases~~~~~~~~~~ The fundamental unit in KUnit is the test case. A test case is a function withthe signature ``void (*)(struct kunit *test)``. It calls a function to be testedand then sets *expectations* for what should happen. For example: .. code-block:: c 	void example_test_success(struct kunit *test)	{	} 	void example_test_failure(struct kunit *test)	{		KUNIT_FAIL(test, "This test never passes.");	} In the above example ``example_test_success`` always passes because it doesnothing; no expectations are set, so all expectations pass. On the other hand``example_test_failure`` always fails because it calls ``KUNIT_FAIL``, which isa special expectation that logs a message and causes the test case to fail. Expectations~~~~~~~~~~~~An *expectation* is a way to specify that you expect a piece of code to dosomething in a test. An expectation is called like a function. A test is madeby setting expectations about the behavior of a piece of code under test; whenone or more of the expectations fail, the test case fails and information aboutthe failure is logged. For example: .. code-block:: c 	void add_test_basic(struct kunit *test)	{		KUNIT_EXPECT_EQ(test, 1, add(1, 0));		KUNIT_EXPECT_EQ(test, 2, add(1, 1));	} In the above example ``add_test_basic`` makes a number of assertions about thebehavior of a function called ``add``; the first parameter is always of type``struct kunit *``, which contains information about the current test context;the second parameter, in this case, is what the value is expected to be; thelast value is what the value actually is. If ``add`` passes all of theseexpectations, the test case, ``add_test_basic`` will pass; if any one of theseexpectations fails, the test case will fail. It is important to understand that a test case *fails* when any expectation isviolated; however, the test will continue running, potentially trying otherexpectations until the test case ends or is otherwise terminated. This is asopposed to *assertions* which are discussed later. To learn about more expectations supported by KUnit, see :doc:`api/test`. .. note::   A single test case should be pretty short, pretty easy to understand,   focused on a single behavior. For example, if we wanted to properly test the add function above, we wouldcreate additional tests cases which would each test a different property that anadd function should have like this: .. code-block:: c 	void add_test_basic(struct kunit *test)	{		KUNIT_EXPECT_EQ(test, 1, add(1, 0));		KUNIT_EXPECT_EQ(test, 2, add(1, 1));	} 	void add_test_negative(struct kunit *test)	{		KUNIT_EXPECT_EQ(test, 0, add(-1, 1));	} 	void add_test_max(struct kunit *test)	{		KUNIT_EXPECT_EQ(test, INT_MAX, add(0, INT_MAX));		KUNIT_EXPECT_EQ(test, -1, add(INT_MAX, INT_MIN));	} 	void add_test_overflow(struct kunit *test)	{		KUNIT_EXPECT_EQ(test, INT_MIN, add(INT_MAX, 1));	} Notice how it is immediately obvious what all the properties that we are testingfor are. Assertions~~~~~~~~~~ KUnit also has the concept of an *assertion*. An assertion is just like anexpectation except the assertion immediately terminates the test case if it isnot satisfied. For example: .. code-block:: c 	static void mock_test_do_expect_default_return(struct kunit *test)	{		struct mock_test_context *ctx = test->priv;		struct mock *mock = ctx->mock;		int param0 = 5, param1 = -5;		const char *two_param_types[] = {"int", "int"};		const void *two_params[] = {&param0, &param1};		const void *ret; 		ret = mock->do_expect(mock,				      "test_printk", test_printk,				      two_param_types, two_params,				      ARRAY_SIZE(two_params));		KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ret);		KUNIT_EXPECT_EQ(test, -4, *((int *) ret));	} In this example, the method under test should return a pointer to a value, soif the pointer returned by the method is null or an errno, we don't want tobother continuing the test since the following expectation could crash the testcase. `ASSERT_NOT_ERR_OR_NULL(...)` allows us to bail out of the test case ifthe appropriate conditions have not been satisfied to complete the test. Test Suites~~~~~~~~~~~ Now obviously one unit test isn't very helpful; the power comes from havingmany test cases covering all of a unit's behaviors. Consequently it is commonto have many *similar* tests; in order to reduce duplication in these closelyrelated tests most unit testing frameworks - including KUnit - provide theconcept of a *test suite*. A *test suite* is just a collection of test casesfor a unit of code with a set up function that gets invoked before every testcase and then a tear down function that gets invoked after every test casecompletes. Example: .. code-block:: c 	static struct kunit_case example_test_cases[] = {		KUNIT_CASE(example_test_foo),		KUNIT_CASE(example_test_bar),		KUNIT_CASE(example_test_baz),		{}	}; 	static struct kunit_suite example_test_suite = {		.name = "example",		.init = example_test_init,		.exit = example_test_exit,		.test_cases = example_test_cases,	};	kunit_test_suite(example_test_suite); In the above example the test suite, ``example_test_suite``, would run the testcases ``example_test_foo``, ``example_test_bar``, and ``example_test_baz``;each would have ``example_test_init`` called immediately before it and wouldhave ``example_test_exit`` called immediately after it.``kunit_test_suite(example_test_suite)`` registers the test suite with theKUnit test framework. .. note::   A test case will only be run if it is associated with a test suite. ``kunit_test_suite(...)`` is a macro which tells the linker to put the specifiedtest suite in a special linker section so that it can be run by KUnit eitherafter late_init, or when the test module is loaded (depending on whether thetest was built in or not). For more information on these types of things see the :doc:`api/test`. Common Patterns=============== Isolating Behavior------------------ The most important aspect of unit testing that other forms of testing do notprovide is the ability to limit the amount of code under test to a single unit.In practice, this is only possible by being able to control what code gets runwhen the unit under test calls a function and this is usually accomplishedthrough some sort of indirection where a function is exposed as part of an APIsuch that the definition of that function can be changed without affecting therest of the code base. In the kernel this primarily comes from two constructs,classes, structs that contain function pointers that are provided by theimplementer, and architecture-specific functions which have definitions selectedat compile time. Classes~~~~~~~ Classes are not a construct that is built into the C programming language;however, it is an easily derived concept. Accordingly, pretty much every projectthat does not use a standardized object oriented library (like GNOME's GObject)has their own slightly different way of doing object oriented programming; theLinux kernel is no exception. The central concept in kernel object oriented programming is the class. In thekernel, a *class* is a struct that contains function pointers. This creates acontract between *implementers* and *users* since it forces them to use thesame function signature without having to call the function directly. In orderfor it to truly be a class, the function pointers must specify that a pointerto the class, known as a *class handle*, be one of the parameters; this makesit possible for the member functions (also known as *methods*) to have accessto member variables (more commonly known as *fields*) allowing the sameimplementation to have multiple *instances*. Typically a class can be *overridden* by *child classes* by embedding the*parent class* in the child class. Then when a method provided by the childclass is called, the child implementation knows that the pointer passed to it isof a parent contained within the child; because of this, the child can computethe pointer to itself because the pointer to the parent is always a fixed offsetfrom the pointer to the child; this offset is the offset of the parent containedin the child struct. For example: .. code-block:: c 	struct shape {		int (*area)(struct shape *this);	}; 	struct rectangle {		struct shape parent;		int length;		int width;	}; 	int rectangle_area(struct shape *this)	{		struct rectangle *self = container_of(this, struct shape, parent); 		return self->length * self->width;	}; 	void rectangle_new(struct rectangle *self, int length, int width)	{		self->parent.area = rectangle_area;		self->length = length;		self->width = width;	} In this example (as in most kernel code) the operation of computing the pointerto the child from the pointer to the parent is done by ``container_of``. Faking Classes~~~~~~~~~~~~~~ In order to unit test a piece of code that calls a method in a class, thebehavior of the method must be controllable, otherwise the test ceases to be aunit test and becomes an integration test. A fake just provides an implementation of a piece of code that is different thanwhat runs in a production instance, but behaves identically from the standpointof the callers; this is usually done to replace a dependency that is hard todeal with, or is slow. A good example for this might be implementing a fake EEPROM that just stores the"contents" in an internal buffer. For example, let's assume we have a class thatrepresents an EEPROM: .. code-block:: c 	struct eeprom {		ssize_t (*read)(struct eeprom *this, size_t offset, char *buffer, size_t count);		ssize_t (*write)(struct eeprom *this, size_t offset, const char *buffer, size_t count);	}; And we want to test some code that buffers writes to the EEPROM: .. code-block:: c 	struct eeprom_buffer {		ssize_t (*write)(struct eeprom_buffer *this, const char *buffer, size_t count);		int flush(struct eeprom_buffer *this);		size_t flush_count; /* Flushes when buffer exceeds flush_count. */	}; 	struct eeprom_buffer *new_eeprom_buffer(struct eeprom *eeprom);	void destroy_eeprom_buffer(struct eeprom *eeprom); We can easily test this code by *faking out* the underlying EEPROM: .. code-block:: c 	struct fake_eeprom {		struct eeprom parent;		char contents[FAKE_EEPROM_CONTENTS_SIZE];	}; 	ssize_t fake_eeprom_read(struct eeprom *parent, size_t offset, char *buffer, size_t count)	{		struct fake_eeprom *this = container_of(parent, struct fake_eeprom, parent); 		count = min(count, FAKE_EEPROM_CONTENTS_SIZE - offset);		memcpy(buffer, this->contents + offset, count); 		return count;	} 	ssize_t fake_eeprom_write(struct eeprom *parent, size_t offset, const char *buffer, size_t count)	{		struct fake_eeprom *this = container_of(parent, struct fake_eeprom, parent); 		count = min(count, FAKE_EEPROM_CONTENTS_SIZE - offset);		memcpy(this->contents + offset, buffer, count); 		return count;	} 	void fake_eeprom_init(struct fake_eeprom *this)	{		this->parent.read = fake_eeprom_read;		this->parent.write = fake_eeprom_write;		memset(this->contents, 0, FAKE_EEPROM_CONTENTS_SIZE);	} We can now use it to test ``struct eeprom_buffer``: .. code-block:: c 	struct eeprom_buffer_test {		struct fake_eeprom *fake_eeprom;		struct eeprom_buffer *eeprom_buffer;	}; 	static void eeprom_buffer_test_does_not_write_until_flush(struct kunit *test)	{		struct eeprom_buffer_test *ctx = test->priv;		struct eeprom_buffer *eeprom_buffer = ctx->eeprom_buffer;		struct fake_eeprom *fake_eeprom = ctx->fake_eeprom;		char buffer[] = {0xff}; 		eeprom_buffer->flush_count = SIZE_MAX; 		eeprom_buffer->write(eeprom_buffer, buffer, 1);		KUNIT_EXPECT_EQ(test, fake_eeprom->contents[0], 0); 		eeprom_buffer->write(eeprom_buffer, buffer, 1);		KUNIT_EXPECT_EQ(test, fake_eeprom->contents[1], 0); 		eeprom_buffer->flush(eeprom_buffer);		KUNIT_EXPECT_EQ(test, fake_eeprom->contents[0], 0xff);		KUNIT_EXPECT_EQ(test, fake_eeprom->contents[1], 0xff);	} 	static void eeprom_buffer_test_flushes_after_flush_count_met(struct kunit *test)	{		struct eeprom_buffer_test *ctx = test->priv;		struct eeprom_buffer *eeprom_buffer = ctx->eeprom_buffer;		struct fake_eeprom *fake_eeprom = ctx->fake_eeprom;		char buffer[] = {0xff}; 		eeprom_buffer->flush_count = 2; 		eeprom_buffer->write(eeprom_buffer, buffer, 1);		KUNIT_EXPECT_EQ(test, fake_eeprom->contents[0], 0); 		eeprom_buffer->write(eeprom_buffer, buffer, 1);		KUNIT_EXPECT_EQ(test, fake_eeprom->contents[0], 0xff);		KUNIT_EXPECT_EQ(test, fake_eeprom->contents[1], 0xff);	} 	static void eeprom_buffer_test_flushes_increments_of_flush_count(struct kunit *test)	{		struct eeprom_buffer_test *ctx = test->priv;		struct eeprom_buffer *eeprom_buffer = ctx->eeprom_buffer;		struct fake_eeprom *fake_eeprom = ctx->fake_eeprom;		char buffer[] = {0xff, 0xff}; 		eeprom_buffer->flush_count = 2; 		eeprom_buffer->write(eeprom_buffer, buffer, 1);		KUNIT_EXPECT_EQ(test, fake_eeprom->contents[0], 0); 		eeprom_buffer->write(eeprom_buffer, buffer, 2);		KUNIT_EXPECT_EQ(test, fake_eeprom->contents[0], 0xff);		KUNIT_EXPECT_EQ(test, fake_eeprom->contents[1], 0xff);		/* Should have only flushed the first two bytes. */		KUNIT_EXPECT_EQ(test, fake_eeprom->contents[2], 0);	} 	static int eeprom_buffer_test_init(struct kunit *test)	{		struct eeprom_buffer_test *ctx; 		ctx = kunit_kzalloc(test, sizeof(*ctx), GFP_KERNEL);		KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ctx); 		ctx->fake_eeprom = kunit_kzalloc(test, sizeof(*ctx->fake_eeprom), GFP_KERNEL);		KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ctx->fake_eeprom);		fake_eeprom_init(ctx->fake_eeprom); 		ctx->eeprom_buffer = new_eeprom_buffer(&ctx->fake_eeprom->parent);		KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ctx->eeprom_buffer); 		test->priv = ctx; 		return 0;	} 	static void eeprom_buffer_test_exit(struct kunit *test)	{		struct eeprom_buffer_test *ctx = test->priv; 		destroy_eeprom_buffer(ctx->eeprom_buffer);	} Testing against multiple inputs------------------------------- Testing just a few inputs might not be enough to have confidence that the codeworks correctly, e.g. for a hash function. In such cases, it can be helpful to have a helper macro or function, e.g. thisfictitious example for ``sha1sum(1)`` .. code-block:: c 	/* Note: the cast is to satisfy overly strict type-checking. */	#define TEST_SHA1(in, want) \		sha1sum(in, out); \		KUNIT_EXPECT_STREQ_MSG(test, (char *)out, want, "sha1sum(%s)", in); 	char out[40];	TEST_SHA1("hello world",  "2aae6c35c94fcfb415dbe95f408b9ce91ee846ed");	TEST_SHA1("hello world!", "430ce34d020724ed75a196dfc2ad67c77772d169");  Note the use of ``KUNIT_EXPECT_STREQ_MSG`` to give more context when it failsand make it easier to track down. (Yes, in this example, ``want`` is likelygoing to be unique enough on its own). The ``_MSG`` variants are even more useful when the same expectation is calledmultiple times (in a loop or helper function) and thus the line number isn'tenough to identify what failed, like below. In some cases, it can be helpful to write a *table-driven test* instead, e.g. .. code-block:: c 	int i;	char out[40]; 	struct sha1_test_case {		const char *str;		const char *sha1;	}; 	struct sha1_test_case cases[] = {		{			.str = "hello world",

Lines 1–500 of 745. Load more