Lines Matching full:test
21 to unit test code that was otherwise un-unit-testable.
39 A `unit test <https://martinfowler.com/bliki/UnitTest.html>`_ is a test that
50 Test Cases
53 The fundamental unit in KUnit is the test case. A test case is a function with
54 the signature ``void (*)(struct kunit *test)``. It calls a function to be tested
59 void example_test_success(struct kunit *test)
63 void example_test_failure(struct kunit *test)
65 KUNIT_FAIL(test, "This test never passes.");
71 a special expectation that logs a message and causes the test case to fail.
76 something in a test. An expectation is called like a function. A test is made
77 by setting expectations about the behavior of a piece of code under test; when
78 one or more of the expectations fail, the test case fails and information about
83 void add_test_basic(struct kunit *test)
85 KUNIT_EXPECT_EQ(test, 1, add(1, 0));
86 KUNIT_EXPECT_EQ(test, 2, add(1, 1));
91 ``struct kunit *``, which contains information about the current test context;
94 expectations, the test case, ``add_test_basic`` will pass; if any one of these
95 expectations fails, the test case will fail.
97 It is important to understand that a test case *fails* when any expectation is
98 violated; however, the test will continue running, potentially trying other
99 expectations until the test case ends or is otherwise terminated. This is as
102 To learn about more expectations supported by KUnit, see :doc:`api/test`.
105 A single test case should be pretty short, pretty easy to understand,
108 For example, if we wanted to properly test the add function above, we would
109 create additional tests cases which would each test a different property that an
114 void add_test_basic(struct kunit *test)
116 KUNIT_EXPECT_EQ(test, 1, add(1, 0));
117 KUNIT_EXPECT_EQ(test, 2, add(1, 1));
120 void add_test_negative(struct kunit *test)
122 KUNIT_EXPECT_EQ(test, 0, add(-1, 1));
125 void add_test_max(struct kunit *test)
127 KUNIT_EXPECT_EQ(test, INT_MAX, add(0, INT_MAX));
128 KUNIT_EXPECT_EQ(test, -1, add(INT_MAX, INT_MIN));
131 void add_test_overflow(struct kunit *test)
133 KUNIT_EXPECT_EQ(test, INT_MIN, add(INT_MAX, 1));
143 expectation except the assertion immediately terminates the test case if it is
150 static void mock_test_do_expect_default_return(struct kunit *test)
152 struct mock_test_context *ctx = test->priv;
163 KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ret);
164 KUNIT_EXPECT_EQ(test, -4, *((int *) ret));
167 In this example, the method under test should return a pointer to a value, so
169 bother continuing the test since the following expectation could crash the test
170 case. `ASSERT_NOT_ERR_OR_NULL(...)` allows us to bail out of the test case if
171 the appropriate conditions have not been satisfied to complete the test.
173 Test Suites
176 Now obviously one unit test isn't very helpful; the power comes from having
177 many test cases covering all of a unit's behaviors. Consequently it is common
180 concept of a *test suite*. A *test suite* is just a collection of test cases
181 for a unit of code with a set up function that gets invoked before every test
182 case and then a tear down function that gets invoked after every test case
204 In the above example the test suite, ``example_test_suite``, would run the test
208 ``kunit_test_suite(example_test_suite)`` registers the test suite with the
209 KUnit test framework.
212 A test case will only be run if it is associated with a test suite.
215 test suite in a special linker section so that it can be run by KUnit either
216 after late_init, or when the test module is loaded (depending on whether the
217 test was built in or not).
219 For more information on these types of things see the :doc:`api/test`.
225 provide is the ability to limit the amount of code under test to a single unit.
227 when the unit under test calls a function and this is usually accomplished
294 In order to unit test a piece of code that calls a method in a class, the
295 behavior of the method must be controllable, otherwise the test ceases to be a
296 unit test and becomes an integration test.
314 And we want to test some code that buffers writes to the EEPROM:
327 We can easily test this code by *faking out* the underlying EEPROM:
363 We can now use it to test ``struct eeprom_buffer``:
372 static void eeprom_buffer_test_does_not_write_until_flush(struct kunit *test)
374 struct eeprom_buffer_test *ctx = test->priv;
382 KUNIT_EXPECT_EQ(test, fake_eeprom->contents[0], 0);
385 KUNIT_EXPECT_EQ(test, fake_eeprom->contents[1], 0);
388 KUNIT_EXPECT_EQ(test, fake_eeprom->contents[0], 0xff);
389 KUNIT_EXPECT_EQ(test, fake_eeprom->contents[1], 0xff);
392 static void eeprom_buffer_test_flushes_after_flush_count_met(struct kunit *test)
394 struct eeprom_buffer_test *ctx = test->priv;
402 KUNIT_EXPECT_EQ(test, fake_eeprom->contents[0], 0);
405 KUNIT_EXPECT_EQ(test, fake_eeprom->contents[0], 0xff);
406 KUNIT_EXPECT_EQ(test, fake_eeprom->contents[1], 0xff);
409 static void eeprom_buffer_test_flushes_increments_of_flush_count(struct kunit *test)
411 struct eeprom_buffer_test *ctx = test->priv;
419 KUNIT_EXPECT_EQ(test, fake_eeprom->contents[0], 0);
422 KUNIT_EXPECT_EQ(test, fake_eeprom->contents[0], 0xff);
423 KUNIT_EXPECT_EQ(test, fake_eeprom->contents[1], 0xff);
425 KUNIT_EXPECT_EQ(test, fake_eeprom->contents[2], 0);
428 static int eeprom_buffer_test_init(struct kunit *test)
432 ctx = kunit_kzalloc(test, sizeof(*ctx), GFP_KERNEL);
433 KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ctx);
435 ctx->fake_eeprom = kunit_kzalloc(test, sizeof(*ctx->fake_eeprom), GFP_KERNEL);
436 KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ctx->fake_eeprom);
440 KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ctx->eeprom_buffer);
442 test->priv = ctx;
447 static void eeprom_buffer_test_exit(struct kunit *test)
449 struct eeprom_buffer_test *ctx = test->priv;
459 By default KUnit uses UML as a way to provide dependencies for code under test.
462 are instances where being able to run architecture-specific code or test
472 * Hardware may not be deterministic, so a test that always passes or fails
503 If you wanted to run this test on an x86 VM, you might add the following config
545 Congratulations, you just ran a KUnit test on the x86 architecture!
560 modprobe example-test
565 Note that you should make sure your test depends on ``KUNIT=y`` in Kconfig
566 if the test does not support module build. Otherwise, it will trigger
573 KUnit test for a specific architecture, and then whether it is necessary to
574 write that test for a particular piece of hardware. In general, writing a test
578 Even if you only ever plan on running your KUnit test on your hardware
580 to your hardware. If you write your test to run on UML, then anyone can run your
591 specific test: for example, you might want to test some code that really belongs
592 in ``arch/some-arch/*``. Even so, try your best to write the test so that it
593 does not depend on physical hardware: if some of your test cases don't need the
599 hardware state in between test cases; if this is not possible, you may only be
600 able to run one test case per invocation.
603 dependent KUnit test.
607 When kunit test suites are initialized, they create an associated directory
608 in ``/sys/kernel/debug/kunit/<test-suite>``. The directory contains one file
610 - results: "cat results" displays results of each test case and the results
611 of the entire suite for the last test run.
613 The debugfs representation is primarily of use when kunit test suites are
617 results file is KUNIT_LOG_SIZE bytes (defined in ``include/kunit/test.h``).