linux.git/lib/kunit/kunit-example-test.c, branch v6.6.131

kunit: Add speed attribute

2023-07-26T19:29:04+00:00

Add speed attribute to the test attribute API. This attribute will allow
users to mark tests with a category of speed.

Currently the categories of speed proposed are: normal, slow, and very_slow
(outlined in enum kunit_speed). These are outlined in the enum kunit_speed.

The assumed default speed for tests is "normal". This indicates that the
test takes a relatively trivial amount of time (less than 1 second),
regardless of the machine it is running on. Any test slower than this could
be marked as "slow" or "very_slow".

Add the macro KUNIT_CASE_SLOW to set a test as slow, as this is likely a
common use of the attributes API.

Add an example of marking a slow test to kunit-example-test.c.

Reviewed-by: David Gow 
Signed-off-by: Rae Moar 
Signed-off-by: Shuah Khan

kunit/test: Add example test showing parameterized testing

2023-05-26T14:43:57+00:00

Use of parameterized testing is documented [1] but such use case
is not present in demo kunit test. Add small subtest for that.

[1] https://kernel.org/doc/html/latest/dev-tools/kunit/usage.html#parameterized-testing

Signed-off-by: Michal Wajdeczko 
Cc: David Gow 
Reviewed-by: David Gow 
Signed-off-by: Shuah Khan

kunit: example: Provide example exit functions

2023-05-12T00:17:41+00:00

Add an example .exit and .suite_exit function to the KUnit example
suite. Given exit functions are a bit more subtle than init functions
(due to running in a different kthread, and running even after tests or
test init functions fail), providing an easy place to experiment with
them is useful.

Reviewed-by: Rae Moar 
Signed-off-by: David Gow 
Signed-off-by: Shuah Khan

kunit: Expose 'static stub' API to redirect functions

2023-02-08T21:28:17+00:00

Add a simple way of redirecting calls to functions by including a
special prologue in the "real" function which checks to see if the
replacement function should be called (and, if so, calls it).

To redirect calls to a function, make the first (non-declaration) line
of the function:

	KUNIT_STATIC_STUB_REDIRECT(function_name, [function arguments]);

(This will compile away to nothing if KUnit is not enabled, otherwise it
will check if a redirection is active, call the replacement function,
and return. This check is protected by a static branch, so has very
little overhead when there are no KUnit tests running.)

Calls to the real function can be redirected to a replacement using:

	kunit_activate_static_stub(test, real_fn, replacement_fn);

The redirection will only affect calls made from within the kthread of
the current test, and will be automatically disabled when the test
completes. It can also be manually disabled with
kunit_deactivate_static_stub().

The 'example' KUnit test suite has a more complete example.

Co-developed-by: Daniel Latypov 
Signed-off-by: Daniel Latypov 
Signed-off-by: David Gow 
Reviewed-by: Brendan Higgins 
Signed-off-by: Shuah Khan

kunit: Add KUnit memory block assertions to the example_all_expect_macros_test

2022-10-27T08:39:59+00:00

Augment the example_all_expect_macros_test with the KUNIT_EXPECT_MEMEQ
and KUNIT_EXPECT_MEMNEQ macros by creating a test with memory block
assertions.

Signed-off-by: Maíra Canal 
Reviewed-by: Daniel Latypov 
Reviewed-by: David Gow 
Signed-off-by: Shuah Khan

kunit: add ability to specify suite-level init and exit functions

2022-05-02T18:35:51+00:00

KUnit has support for setup/cleanup logic for each test case in a suite.
But it lacks the ability to specify setup/cleanup for the entire suite
itself.

This can be used to do setup that is too expensive or cumbersome to do
for each test.
Or it can be used to do simpler things like log debug information after
the suite completes.
It's a fairly common feature, so the lack of it is noticeable.

Some examples in other frameworks and languages:
* https://docs.python.org/3/library/unittest.html#setupclass-and-teardownclass
* https://google.github.io/googletest/reference/testing.html#Test::SetUpTestSuite

Meta:
This is very similar to this patch here: https://lore.kernel.org/linux-kselftest/20210805043503.20252-3-bvanassche@acm.org/
The changes from that patch:
* pass in `struct kunit *` so users can do stuff like
  `kunit_info(suite, "debug message")`
* makes sure the init failure is bubbled up as a failure
* updates kunit-example-test.c to use a suite init
* Updates kunit/usage.rst to mention the new support
* some minor cosmetic things
  * use `suite_{init,exit}` instead of `{init/exit}_suite`
  * make suite init error message more consistent w/ test init
  * etc.

Signed-off-by: Daniel Latypov 
Reviewed-by: David Gow 
Reviewed-by: Brendan Higgins 
Signed-off-by: Shuah Khan

kunit: use NULL macros

2022-04-04T20:29:08+00:00

Replace the NULL checks with the more specific and idiomatic NULL macros.

Reviewed-by: Brendan Higgins 
Reviewed-by: Daniel Latypov 
Signed-off-by: Ricardo Ribalda 
Signed-off-by: Shuah Khan

kunit: add example test case showing off all the expect macros

2022-01-25T19:49:20+00:00

Currently, these macros are only really documented near the bottom of
https://www.kernel.org/doc/html/latest/dev-tools/kunit/api/test.html#c.KUNIT_FAIL.

E.g. it's likely someone might just not realize that
KUNIT_EXPECT_STREQ() exists and instead use KUNIT_EXPECT_FALSE(strcmp())
or similar.

This can also serve as a basic smoketest that the KUnit assert machinery
still works for all the macros.

Signed-off-by: Daniel Latypov 
Reviewed-by: Brendan Higgins 
Reviewed-by: David Gow 
Signed-off-by: Shuah Khan

kunit: test: Add example tests which are always skipped

2021-06-25T17:31:03+00:00

Add two new tests to the example test suite, both of which are always
skipped. This is used as an example for how to write tests which are
skipped, and to demonstrate the difference between kunit_skip() and
kunit_mark_skipped().

Note that these tests are enabled by default, so a default run of KUnit
will have two skipped tests.

Signed-off-by: David Gow 
Reviewed-by: Daniel Latypov 
Reviewed-by: Brendan Higgins 
Reviewed-by: Marco Elver 
Signed-off-by: Shuah Khan

kunit: allow kunit tests to be loaded as a module

2020-01-09T23:42:29+00: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 
Signed-off-by: Knut Omang 
Signed-off-by: Alan Maguire 
Reviewed-by: Brendan Higgins 
Acked-by: Theodore Ts'o  # for ext4 bits
Acked-by: David Gow  # For list-test
Reported-by: kbuild test robot 
Signed-off-by: Shuah Khan