mirror of
				https://github.com/torvalds/linux.git
				synced 2025-11-04 10:40:15 +02:00 
			
		
		
		
	As tests are added to kunit, it will become less feasible to execute
all built tests together.  By supporting modular tests we provide
a simple way to do selective execution on a running system; specifying
CONFIG_KUNIT=y
CONFIG_KUNIT_EXAMPLE_TEST=m
...means we can simply "insmod example-test.ko" to run the tests.
To achieve this we need to do the following:
o export the required symbols in kunit
o string-stream tests utilize non-exported symbols so for now we skip
  building them when CONFIG_KUNIT_TEST=m.
o drivers/base/power/qos-test.c contains a few unexported interface
  references, namely freq_qos_read_value() and freq_constraints_init().
  Both of these could be potentially defined as static inline functions
  in include/linux/pm_qos.h, but for now we simply avoid supporting
  module build for that test suite.
o support a new way of declaring test suites.  Because a module cannot
  do multiple late_initcall()s, we provide a kunit_test_suites() macro
  to declare multiple suites within the same module at once.
o some test module names would have been too general ("test-test"
  and "example-test" for kunit tests, "inode-test" for ext4 tests);
  rename these as appropriate ("kunit-test", "kunit-example-test"
  and "ext4-inode-test" respectively).
Also define kunit_test_suite() via kunit_test_suites()
as callers in other trees may need the old definition.
Co-developed-by: Knut Omang <knut.omang@oracle.com>
Signed-off-by: Knut Omang <knut.omang@oracle.com>
Signed-off-by: Alan Maguire <alan.maguire@oracle.com>
Reviewed-by: Brendan Higgins <brendanhiggins@google.com>
Acked-by: Theodore Ts'o <tytso@mit.edu> # for ext4 bits
Acked-by: David Gow <davidgow@google.com> # For list-test
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
		
	
			
		
			
				
	
	
		
			90 lines
		
	
	
	
		
			2.6 KiB
		
	
	
	
		
			C
		
	
	
	
	
	
			
		
		
	
	
			90 lines
		
	
	
	
		
			2.6 KiB
		
	
	
	
		
			C
		
	
	
	
	
	
// SPDX-License-Identifier: GPL-2.0
 | 
						|
/*
 | 
						|
 * Example KUnit test to show how to use KUnit.
 | 
						|
 *
 | 
						|
 * Copyright (C) 2019, Google LLC.
 | 
						|
 * Author: Brendan Higgins <brendanhiggins@google.com>
 | 
						|
 */
 | 
						|
 | 
						|
#include <kunit/test.h>
 | 
						|
 | 
						|
/*
 | 
						|
 * This is the most fundamental element of KUnit, the test case. A test case
 | 
						|
 * makes a set EXPECTATIONs and ASSERTIONs about the behavior of some code; if
 | 
						|
 * any expectations or assertions are not met, the test fails; otherwise, the
 | 
						|
 * test passes.
 | 
						|
 *
 | 
						|
 * In KUnit, a test case is just a function with the signature
 | 
						|
 * `void (*)(struct kunit *)`. `struct kunit` is a context object that stores
 | 
						|
 * information about the current test.
 | 
						|
 */
 | 
						|
static void example_simple_test(struct kunit *test)
 | 
						|
{
 | 
						|
	/*
 | 
						|
	 * This is an EXPECTATION; it is how KUnit tests things. When you want
 | 
						|
	 * to test a piece of code, you set some expectations about what the
 | 
						|
	 * code should do. KUnit then runs the test and verifies that the code's
 | 
						|
	 * behavior matched what was expected.
 | 
						|
	 */
 | 
						|
	KUNIT_EXPECT_EQ(test, 1 + 1, 2);
 | 
						|
}
 | 
						|
 | 
						|
/*
 | 
						|
 * This is run once before each test case, see the comment on
 | 
						|
 * example_test_suite for more information.
 | 
						|
 */
 | 
						|
static int example_test_init(struct kunit *test)
 | 
						|
{
 | 
						|
	kunit_info(test, "initializing\n");
 | 
						|
 | 
						|
	return 0;
 | 
						|
}
 | 
						|
 | 
						|
/*
 | 
						|
 * Here we make a list of all the test cases we want to add to the test suite
 | 
						|
 * below.
 | 
						|
 */
 | 
						|
static struct kunit_case example_test_cases[] = {
 | 
						|
	/*
 | 
						|
	 * This is a helper to create a test case object from a test case
 | 
						|
	 * function; its exact function is not important to understand how to
 | 
						|
	 * use KUnit, just know that this is how you associate test cases with a
 | 
						|
	 * test suite.
 | 
						|
	 */
 | 
						|
	KUNIT_CASE(example_simple_test),
 | 
						|
	{}
 | 
						|
};
 | 
						|
 | 
						|
/*
 | 
						|
 * This defines a suite or grouping of tests.
 | 
						|
 *
 | 
						|
 * Test cases are defined as belonging to the suite by adding them to
 | 
						|
 * `kunit_cases`.
 | 
						|
 *
 | 
						|
 * Often it is desirable to run some function which will set up things which
 | 
						|
 * will be used by every test; this is accomplished with an `init` function
 | 
						|
 * which runs before each test case is invoked. Similarly, an `exit` function
 | 
						|
 * may be specified which runs after every test case and can be used to for
 | 
						|
 * cleanup. For clarity, running tests in a test suite would behave as follows:
 | 
						|
 *
 | 
						|
 * suite.init(test);
 | 
						|
 * suite.test_case[0](test);
 | 
						|
 * suite.exit(test);
 | 
						|
 * suite.init(test);
 | 
						|
 * suite.test_case[1](test);
 | 
						|
 * suite.exit(test);
 | 
						|
 * ...;
 | 
						|
 */
 | 
						|
static struct kunit_suite example_test_suite = {
 | 
						|
	.name = "example",
 | 
						|
	.init = example_test_init,
 | 
						|
	.test_cases = example_test_cases,
 | 
						|
};
 | 
						|
 | 
						|
/*
 | 
						|
 * This registers the above test suite telling KUnit that this is a suite of
 | 
						|
 * tests that need to be run.
 | 
						|
 */
 | 
						|
kunit_test_suites(&example_test_suite);
 | 
						|
 | 
						|
MODULE_LICENSE("GPL v2");
 |