Lines Matching refs:test
7 This tool aims to test U-Boot by executing U-Boot shell commands using the
14 - There is no need to write or embed test-related code into U-Boot itself.
15 It is asserted that writing test-related code in Python is simpler and more
22 The test suite is implemented using pytest. Interaction with the U-Boot console
24 need to implement various "hook" scripts that are called by the test suite at
27 In order to run the test suite at a minimum we require that both Python 3 and
29 described in the requirements.txt file in the /test/py/ directory and can be
57 The test script supports either:
68 The recommended way to run the test suite, in order to ensure reproducibility
79 $ pip install -r test/py/requirements.txt
84 To run the test suite on the sandbox port (U-Boot built as a native user-space
89 ./test/py/test.py --bd sandbox --build
91 The `--bd` option tells the test suite which board type is being tested. This
92 lets the test suite know which features the board has, and hence exactly what
97 running the test script.
99 The test script will attach to U-Boot, execute all valid tests for the board,
100 then print a summary of the test process. A complete log of the test session
101 will be written to `${build_dir}/test-log.html`. This is best viewed in a web
125 ./test/py/test.py --bd sandbox --gdbserver localhost:1234
139 Some tests deliberately cause the sandbox process to exit, e.g. to test the
155 test script in any way, but rather is simply passed to the hook scripts
159 indicates that the test script should compile U-Boot itself before running
176 sets the directory used to store persistent test data. This is test data that
177 may be re-used across test runs, such as file-system images.
181 details. Execute `py.test --version` for a brief summary. Note that U-Boot's
182 test.py script passes all command-line arguments directly to `pytest` for
187 option takes a single argument which is used to filter test names. Simple
192 case, "ut_dm" is a parameter to a test rather than the test name. The full
193 test name is e.g. "test_ut[ut_dm_leak]".
200 prevents pytest from hiding a test's stdout. This allows you to see
208 For this reason, the test suite does not attempt to directly interact with real
210 via `$PATH`. These scripts implement certain actions on behalf of the test
211 suite. This keeps the test suite simple and isolated from system variances
226 - `UBOOT_TEST_PY_DIR` the full path to `test/py/` in the source directory.
228 - `UBOOT_RESULT_DIR` the test result directory.
229 - `UBOOT_PERSISTENT_DATA_DIR` the test persistent data directory.
231 u-boot-test-console
236 indefinitely, until killed. The test suite will run this script in parallel
244 `u-boot-test-reset` may be called multiple times per test script run, and must
247 simulator from `u-boot-test-reset` instead, while arranging for this console
250 u-boot-test-flash
253 Prior to running the test suite against a board, some arrangement must be made
255 this involves writing the U-Boot binary to the board's flash ROM. The test
266 board's flash prior to running the test suite.
270 required. If this feature is used, the `u-boot-test-reset` script should
272 times in a single test run.
280 u-boot-test-reset
283 Whenever the test suite needs to reset the target board, this script is
285 first test function. If any test fails, the test infra-structure will execute
287 next test function.
298 avoid the need for `u-boot-test-flash` to actually write U-Boot to flash, thus
304 https://source.denx.de/u-boot/u-boot-test-hooks contains some working example hook
316 to provide board-specific information to the test script. Any global value
317 defined in these modules is available for use by any test function. The data
328 machine running the test script.
332 board-specific and board-identity-specific information to the test script. Any
333 global value defined in these modules is available for use by any test
337 should set `$PYTHONPATH` prior to running the test script to allow these
343 The test scripts rely on the following variables being defined by the board
351 The test scripts rely on various U-Boot `.config` features, either directly in
352 order to test those features, or indirectly in order to query information from
353 the running U-Boot instance in order to test other features.
356 address to use for the test. This data is parsed from the output of the
359 For a complete list of dependencies, please search the test scripts for
371 then you would likely invoke the test script as follows:
379 ./test/py/test.py --bd seaboard
381 If you want the test script to compile U-Boot for you too, then you likely
382 need to set `$CROSS_COMPILE` to allow this, and invoke the test script as
390 ./test/py/test.py --bd seaboard --build
398 ./test/py/test.py --bd seaboard --build --buildman
404 Details specific to the U-Boot test suite are described below.
406 A test fixture named `u_boot_console` should be used by each test function. This
416 "bad" strings. Some test scenarios are expected to trigger these strings. Use