Lines Matching refs:tests
17 tests for different boards and different configurations to help keep the
55 you can build and run all possible tests using the following options:
71 This will build for all available boards and run all applicable tests in
74 If you want to run tests on one or more specific platforms, you can use
100 To build tests for a specific board and to execute some of the tests on real
165 By default, tests will be executed using the first entry in the simulation array. Another
168 tests will be built only.
169 If it is not set and the required simulator is not available the tests will fail to run.
216 Do not attempt to build (and therefore run) tests marked with this list of
219 Only execute tests with this list of tags on a specific platform.
242 configuration file may contain one or more entries in the ``tests:`` section each
278 * ``kernel.semaphore``: For general semaphore tests
287 * **Ztest tests**:
292 * **Standalone tests and samples**:
316 tests:
330 A sample with tests will have the same structure with additional information
338 tests:
341 tags: tests
347 tags: tests
350 A Test Scenario entry in the ``tests:`` YAML dictionary has its Test Scenario
361 of this script can filter the set of tests to run based on tag.
364 skip test scenario unconditionally. This can be used for broken tests for
384 tests:
402 tests:
416 tests:
429 This keyword is reserved for tests that are used to test if some code
440 used in CI for increased coverage. Do not use this flag in new tests.
503 generated devicetree and Kconfig will be used for filtering tests.
507 in tests requiring sysbuild support being skipped.
517 keyboard harness is set on tests that require keyboard interaction to reach
533 harness if you've already got tests written in the gTest framework and do
548 BabbleSim's tests to directly run after. By default, the executable file
558 tests and code as passing. The platform_key attribute enables doing just
573 building and running SPI tests once for each unique IP block.
656 be unique across all tests in the test suite.
721 tests:
734 tests:
751 tests:
761 tests:
774 tests:
863 snippets. Listed snippets will filter supported tests for boards (snippets
871 tests:
899 tests, the testing tools should be able to adapt the scope and select/filter out what
924 Managing tests timeouts
927 There are several parameters which control tests timeouts on various levels:
946 the scope of builds and tests if applicable to platforms defined under the
951 Running tests on custom emulator
991 Beside being able to run tests in QEMU and other simulated environments,
992 twister supports running most of the tests on real devices and produces
996 Executing tests on a single device
1009 --device-serial-baud 115200 -p frdm_k64f -T tests/kernel
1016 --device-serial-baud 115200 -p frdm_k64f -T tests/kernel
1036 -p intel_adsp/cavs25 -T tests/kernel
1055 Executing tests on multiple devices
1058 To build and execute tests on multiple devices connected to the host PC, a
1168 With the hardware map ready, you can run any tests by pointing to the map
1184 The above command will result in twister building tests for the platforms
1185 defined in the hardware map and subsequently flashing and running the tests
1245 Some tests require additional setup or special wiring specific to the test.
1246 Running the tests without this setup or test fixture may fail. A test scenario can
1266 and these tests will be executed on the boards that provide this fixture.
1326 with names separated by spaces. This allows to run tests for
1344 Twister allows user to provide configuration files defining a list of tests or
1345 platforms to be put under quarantine. Such tests will be skipped and marked
1348 of other tests (e.g. putting the physical board in a corrupted state).
1353 The current status of tests on the quarantine list can also be verified by adding
1354 ``--quarantine-verify`` to the above argument. This will make twister skip all tests
1363 When quarantining a class of tests or many scenarios in a single testsuite or
1366 all kernel tests.
1392 Additionally you can quarantine entire architectures or a specific simulator for executing tests.
1404 twister it is then possible to select a level and just execute the tests
1408 dependencies and additional inclusion of tests into a specific level if
1420 (Those are mostly emulation platforms used to run tests in upstream
1425 This will treat tests or sample as any other just build for default
1442 only build and run tests on the specified platforms.
1462 additional inclusion of tests into a specific test level if the test itself
1528 -T tests --level="smoke"
1535 run your tests in random order. This can be beneficial for identifying
1546 At this moment Zephyr integration supports running Robot tests in the `Renode <https://renode.io/>`…
1564 Writing Robot tests
1569 Information on writing and running Robot Framework tests in Renode can be found in `the testing sec…
1582 $ twister -p qemu_riscv32 -s tests/kernel/interrupt/arch.shared_interrupt