Lines Matching refs:test
13 There are two basic types of test in U-Boot:
15 - Python tests, in test/py/tests
16 - C tests, in test/ and its subdirectories
21 real hardware. They typically do not require building test code into U-Boot
32 Regardless of which test type is used, all tests are collected and run by the
38 This table shows how to decide whether to write a C or Python test:
41 Attribute C test Python test
44 Easy to write? Yes, if required test Yes
47 Needs code in U-Boot? Yes No, provided the test can be
66 Typically in U-Boot we encourage C test using sandbox for all features. This
68 without needing dozens of boards to test with.
70 When a test requires setup or interaction with the running host (such as to
80 The best of both worlds is sometimes to have a Python test set things up and
81 perform some operations, with a 'checker' C unit test doing the checks
84 - Add the `UT_TESTF_MANUAL` flag to the checker test so that the `ut` command
88 In your Python test use the `-f` flag to the `ut` command to force the checker
89 test to run it, e.g.::
98 Note that apart from the `UT_TESTF_MANUAL` flag, the code in a 'manual' C test
99 is just like any other C test. It still uses ut_assert...() and other such
101 Python test.
108 test and connecting to it via a pipe. Each interaction with the U-Boot process
109 requires at least a context switch to handle the pipe interaction. The test
111 test sees that and continues. Of course on real hardware, communications delays
114 For comparison, consider a test that checks the 'md' (memory dump). All times
115 below are approximate, as measured on an AMD 2950X system. Here is is the test
136 itself it takes around 800ms, including test collection. For 1000 runs it takes
140 There is no exactly equivalent C test, but here is a similar one that tests 'ms'
176 So overall running a C test is perhaps 8 times faster individually and the
179 It should also be noted that the C test is fairly easy to debug. You can set a
191 - test-driven development relies on quick iteration of build/test
193 all sandbox tests typically takes 90 seconds and running each qemu test
206 some common test tasks.
210 Add a new driver model test
213 Use this when adding a test for a new or existing uclass, adding new operations
217 Find a suitable place for your test, perhaps near other test functions in
218 existing code, or in a new file. Each uclass should have its own test file.
220 Declare the test with::
225 /* test code here */
234 The flags for DM_TEST() are defined in test/test.h and you typically want
237 the test runner knows it is a driver model test.
240 recreated anew for each test. This ensures that if a previous test deletes a
250 Add a C test to an existing suite
257 with the suite. For example, to add a new mem_search test::
262 /* test code here*/
275 Add a new test suite
281 Create a new file in test/ or a subdirectory and define a macro to register the
287 #include <dm/test.h>
288 #include <test/ut.h>
290 /* Declare a new wibble test */
307 Register this new suite in test/cmd_ut.c by adding to cmd_ut_sub[]::
320 Finally, add the test to the build by adding to the Makefile in the same
325 Note that CMDLINE is never enabled in SPL, so this test will only be present in
335 Example commit: 919e7a8fb64 ("test: Add a simple test for bloblist") [1]
340 Making the test run from pytest
345 'ut' subcommand for your test suite, it will run. The same applies for driver
348 See test/py/tests/test_ut.py for how unit tests are run.
351 Add a C test for SPL
363 To create a new SPL test, follow the same rules as above, either adding to an
366 An example SPL test is spl_test_load().
373 should be able to use the existing tests in test/py/tests as examples.