Lines Matching full:test
21 possible 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
103 Documentation/dev-tools/kunit/api/test.rst.
106 A single test case should be pretty short, pretty easy to understand,
109 For example, if we wanted to properly test the add function above, we would
110 create additional tests cases which would each test a different property that an
115 void add_test_basic(struct kunit *test)
117 KUNIT_EXPECT_EQ(test, 1, add(1, 0));
118 KUNIT_EXPECT_EQ(test, 2, add(1, 1));
121 void add_test_negative(struct kunit *test)
123 KUNIT_EXPECT_EQ(test, 0, add(-1, 1));
126 void add_test_max(struct kunit *test)
128 KUNIT_EXPECT_EQ(test, INT_MAX, add(0, INT_MAX));
129 KUNIT_EXPECT_EQ(test, -1, add(INT_MAX, INT_MIN));
132 void add_test_overflow(struct kunit *test)
134 KUNIT_EXPECT_EQ(test, INT_MIN, add(INT_MAX, 1));
144 expectation except the assertion immediately terminates the test case if it is
151 static void mock_test_do_expect_default_return(struct kunit *test)
153 struct mock_test_context *ctx = test->priv;
164 KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ret);
165 KUNIT_EXPECT_EQ(test, -4, *((int *) ret));
168 In this example, the method under test should return a pointer to a value, so
170 bother continuing the test since the following expectation could crash the test
171 case. `ASSERT_NOT_ERR_OR_NULL(...)` allows us to bail out of the test case if
172 the appropriate conditions have not been satisfied to complete the test.
174 Test Suites
177 Now obviously one unit test isn't very helpful; the power comes from having
178 many test cases covering all of a unit's behaviors. Consequently it is common
181 concept of a *test suite*. A *test suite* is just a collection of test cases
182 for a unit of code with a set up function that gets invoked before every test
183 case and then a tear down function that gets invoked after every test case
205 In the above example the test suite, ``example_test_suite``, would run the test
209 ``kunit_test_suite(example_test_suite)`` registers the test suite with the
210 KUnit test framework.
213 A test case will only be run if it is associated with a test suite.
216 test suite in a special linker section so that it can be run by KUnit either
217 after late_init, or when the test module is loaded (depending on whether the
218 test was built in or not).
221 Documentation/dev-tools/kunit/api/test.rst.
230 provide is the ability to limit the amount of code under test to a single unit.
232 when the unit under test calls a function and this is usually accomplished
299 In order to unit test a piece of code that calls a method in a class, the
300 behavior of the method must be controllable, otherwise the test ceases to be a
301 unit test and becomes an integration test.
319 And we want to test some code that buffers writes to the EEPROM:
332 We can easily test this code by *faking out* the underlying EEPROM:
368 We can now use it to test ``struct eeprom_buffer``:
377 static void eeprom_buffer_test_does_not_write_until_flush(struct kunit *test)
379 struct eeprom_buffer_test *ctx = test->priv;
387 KUNIT_EXPECT_EQ(test, fake_eeprom->contents[0], 0);
390 KUNIT_EXPECT_EQ(test, fake_eeprom->contents[1], 0);
393 KUNIT_EXPECT_EQ(test, fake_eeprom->contents[0], 0xff);
394 KUNIT_EXPECT_EQ(test, fake_eeprom->contents[1], 0xff);
397 static void eeprom_buffer_test_flushes_after_flush_count_met(struct kunit *test)
399 struct eeprom_buffer_test *ctx = test->priv;
407 KUNIT_EXPECT_EQ(test, fake_eeprom->contents[0], 0);
410 KUNIT_EXPECT_EQ(test, fake_eeprom->contents[0], 0xff);
411 KUNIT_EXPECT_EQ(test, fake_eeprom->contents[1], 0xff);
414 static void eeprom_buffer_test_flushes_increments_of_flush_count(struct kunit *test)
416 struct eeprom_buffer_test *ctx = test->priv;
424 KUNIT_EXPECT_EQ(test, fake_eeprom->contents[0], 0);
427 KUNIT_EXPECT_EQ(test, fake_eeprom->contents[0], 0xff);
428 KUNIT_EXPECT_EQ(test, fake_eeprom->contents[1], 0xff);
430 KUNIT_EXPECT_EQ(test, fake_eeprom->contents[2], 0);
433 static int eeprom_buffer_test_init(struct kunit *test)
437 ctx = kunit_kzalloc(test, sizeof(*ctx), GFP_KERNEL);
438 KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ctx);
440 ctx->fake_eeprom = kunit_kzalloc(test, sizeof(*ctx->fake_eeprom), GFP_KERNEL);
441 KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ctx->fake_eeprom);
445 KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ctx->eeprom_buffer);
447 test->priv = ctx;
452 static void eeprom_buffer_test_exit(struct kunit *test)
454 struct eeprom_buffer_test *ctx = test->priv;
472 KUNIT_EXPECT_STREQ_MSG(test, out, want, "sha1sum(%s)", in);
487 In some cases, it can be helpful to write a *table-driven test* instead, e.g.
511 KUNIT_EXPECT_STREQ_MSG(test, out, cases[i].sha1,
520 * E.g. see ``fs/ext4/inode-test.c`` for an example of both.
521 * reduce duplication if test cases can be shared across multiple tests.
523 * E.g. if we wanted to also test ``sha256sum``, we could add a ``sha256``
526 * be converted to a "parameterized test", see below.
534 Reusing the same ``cases`` array from above, we can write the test as a
535 "parameterized test" with the following.
555 // Need a helper function to generate a name for each test case.
563 // Looks no different from a normal test.
564 static void sha1_test(struct kunit *test)
567 // The former `cases[i]` is accessible under test->param_value.
569 struct sha1_test_case *test_param = (struct sha1_test_case *)(test->param_value);
572 KUNIT_EXPECT_STREQ_MSG(test, out, test_param->sha1,
588 By default KUnit uses UML as a way to provide dependencies for code under test.
591 are instances where being able to run architecture-specific code or test
601 * Hardware may not be deterministic, so a test that always passes or fails
660 If you wanted to run this test on an x86 VM, you might add the following config
702 Congratulations, you just ran a KUnit test on the x86 architecture!
717 modprobe example-test
722 Note that you should make sure your test depends on ``KUNIT=y`` in Kconfig
723 if the test does not support module build. Otherwise, it will trigger
730 KUnit test for a specific architecture, and then whether it is necessary to
731 write that test for a particular piece of hardware. In general, writing a test
735 Even if you only ever plan on running your KUnit test on your hardware
737 to your hardware. If you write your test to run on UML, then anyone can run your
748 specific test: for example, you might want to test some code that really belongs
749 in ``arch/some-arch/*``. Even so, try your best to write the test so that it
750 does not depend on physical hardware: if some of your test cases don't need the
756 hardware state in between test cases; if this is not possible, you may only be
757 able to run one test case per invocation.
760 dependent KUnit test.
764 When kunit test suites are initialized, they create an associated directory
765 in ``/sys/kernel/debug/kunit/<test-suite>``. The directory contains one file
767 - results: "cat results" displays results of each test case and the results
768 of the entire suite for the last test run.
770 The debugfs representation is primarily of use when kunit test suites are
774 results file is KUNIT_LOG_SIZE bytes (defined in ``include/kunit/test.h``).