Lines Matching full:test
3 Test Framework
6 The Zephyr Test Framework (Ztest) provides a simple testing framework intended
8 test structure.
13 Creating a test suite
16 Using Ztest to create a test suite is as easy as calling the :c:macro:`ZTEST_SUITE`. The macro
21 test will run. The predicate will get a pointer to the global state passed in through
23 * :c:type:`ztest_suite_setup_t` - An optional setup function which returns a test fixture. This
24 will be called and run once per test suite run.
26 test in this suite.
28 test in this suite.
32 Below is an example of a test suite using a predicate:
49 There are 5 macros used to add a test to a suite, they are:
51 * :c:macro:`ZTEST` ``(suite_name, test_name)`` - Which can be used to add a test by ``test_name`` t…
53 * :c:macro:`ZTEST_P` ``(suite_name, test_name)`` - Add a parameterized test to a given suite by spe…
55 the body of the test using the ``data`` pointer.
57 that when :kconfig:option:`CONFIG_USERSPACE` is enabled, then the test will be run in a userspace
60 that the test function will already include a variable named ``fixture`` with the type
63 :c:macro:`ZTEST_F` with the userspace threading for the test.
65 Test fixtures
68 Test fixtures can be used to help simplify repeated test setup operations. In many cases, tests in
69 the same suite will require some initial setup followed by some form of reset between each test.
113 Using memory allocated by a test fixture in a userspace thread, such as during execution of
122 Test result expectations
125 Some tests were made to be broken. In cases where the test is expected to fail or skip due to the
126 nature of the code, it's possible to annotate the test as such. For example:
137 /** This will fail the test */
144 /** This will skip the test */
151 Test rules
154 Test rules are a way to run the same logic for every test and every suite. There are a lot of cases
155 where you might want to reset some state for every test in the binary (regardless of which suite is
170 static void fff_reset_rule_before(const struct ztest_unit_test *test, void *fixture)
172 ARG_UNUSED(test);
187 Assuming there's a board with several steps in the power-on sequence a test suite can be written
222 To make a test application for the **bar** component of **foo**, you should copy the
223 sample folder to ``tests/foo/bar`` and edit files there adjusting for your test
226 To build and execute all applicable test scenarios defined in your test application
233 To select just one of the test scenarios, run Twister with ``--scenario`` command:
237 ./scripts/twister --scenario tests/foo/bar/your.test.scenario.name
239 In the command line above ``tests/foo/bar`` is the path to your test application and
240 ``your.test.scenario.name`` references a test scenario defined in :file:`testcase.yaml`
241 file, which is like ``sample.testing.ztest`` in the boilerplate test suite sample.
243 See :ref:`Twister test project diagram <twister_test_project_diagram>` for more details
279 A test application may consist of multiple test suites that
280 either can be testing functionality or APIs. Functions implementing a test case
283 * Test cases function names should be prefixed with **test_**
284 * Test cases should be documented using doxygen
285 * Test case function names should be unique within the section or component being
293 * @brief Test Asserts
295 * This test case verifies the zassert_true macro.
305 Tests (test applications) in the Zephyr tree consist of many test scenarios that run as
306 part of a project and test similar functionality, for example an API or a
307 feature. The ``twister`` script can parse the test scenarios, suites and cases in all
308 test applications or a subset of them, and can generate reports on a granular
309 level, i.e. if test cases have passed or failed or if they were blocked or skipped.
311 Twister parses the source files looking for test case names, so you
312 can list all kernel test cases, for example, by running:
323 report them as being skipped. Because the test inventory and
325 conditionals inside the test suite is sub-optimal. Tests that need
327 report a skip using :c:func:`ztest_test_skip` or :c:macro:`Z_TEST_SKIP_IFDEF`. If the test runs,
378 depends on, you have to provide function stubs in the test. Ztest provides
381 In a unit test, mock objects can simulate the behavior of complex real objects
382 and are used to decide whether a test failed or passed by verifying whether an
386 Best practices for declaring the test suite
390 test cases that a Zephyr *ztest* test image will expose.
395 have only a semaphore test application. We also need to show that we
399 The idea is that test reports show results for every test case
401 high-level test application, particularly when tests do too
411 - Why not declare them in the YAML test configuration?
413 A separate test case description file would be harder to maintain
414 than just keeping the information in the test source files
418 Stress test framework
421 Zephyr stress test framework (Ztress) provides an environment for executing user
435 The stress test environment is setup and executed using :c:macro:`ZTRESS_EXECUTE` which
441 and the macro returns. Note that while the test is executing, a progress report is
444 Execution can be prematurely completed by specifying a test timeout (:c:func:`ztress_set_timeout`)
455 the test to achieve the highest CPU load.
471 - :kconfig:option:`CONFIG_ZTRESS_REPORT_PROGRESS_MS` - Test progress report interval.
484 These macros will instantly fail the test if the related assertion fails.
488 file and line numbers, reducing the binary size of the test.
496 Aborted at unit test function
504 These macros will continue test execution if the related expectation fails and subsequently fail the
505 test at the end of its execution. When an expectation fails, it will print the current file, line,
507 test. If the config :kconfig:option:`CONFIG_ZTEST_ASSERT_VERBOSE` is 0, the expectations will only …
508 file and line numbers, reducing the binary size of the test.
531 These macros will instantly skip the test or suite if the related assumption fails.
535 file and line numbers, reducing the binary size of the test.
577 Customizing Test Output
597 Shuffling Test Sequence
599 By default the tests are sorted and ran in alphanumerical order. Test cases may
601 randomize the order. The output from the test will display the seed for failed
608 By default the tests are executed once. The test cases and test suites
611 means every test suite is executed 3 times and every test case is executed 3 times. This can
615 Test Selection
618 or select tests to run. The test argument expects a comma separated list
619 of ``suite::test`` . You can substitute the test name with an ``*`` to run all
627 $ zephyr.exe -test="fixture_tests::test_fixture_pointer,framework_tests::test_assert_mem_equal"
628 $ zephyr.exe -test="framework_tests::*"