Lines Matching +full:bsim +full:- +full:tests
13 :ref:`bsim boards<bsim boards>`
15 When we build Zephyr targeting a :ref:`bsim board<bsim boards>` we produce a Linux
29 Types of tests
32 Tests without radio activity: bsim tests with twister argument
35 The :ref:`bsim boards<bsim boards>` can be used without radio activity, and in that case, it is not
38 to run all standard Zephyr twister tests, but with models of a real SOC HW, and their drivers.
40 Tests with radio activity
43 When there is radio activity, BabbleSim tests require at the very least a physical layer simulation
44 running, and most, more than 1 simulated device. Due to this, these tests are not build and run
45 with twister, but with a dedicated set of tests scripts.
47 These tests are kept in the :code:`tests/bsim/` folder. The ``compile.sh`` and ``run_parallel.sh``
49 these tests in batch.
54 There are two main sets of tests:
56 * Self checking embedded application/tests: In which some of the simulated devices applications are
58 applications tests use the :ref:`bs_tests<bsim_boards_bs_tests>` system to report the pass or
59 failure, and in many cases to build several tests into the same binary.
63 Today these tests include a very significant subset of the BT qualification test suite.
65 More information about how different tests types relate to BabbleSim and the bsim boards can be
66 found in the :ref:`bsim boards tests section<bsim_boards_tests>`.
75 You can use the script :zephyr_file:`tests/bsim/generate_coverage_report.sh` to generate an html
76 coverage report from tests.
86 Building and running the tests
94 .. code-block:: bash
96 # Build all the tests
97 ${ZEPHYR_BASE}/tests/bsim/compile.sh
101 SEARCH_PATH=${ZEPHYR_BASE}/tests/bsim \
102 ${ZEPHYR_BASE}/tests/bsim/run_parallel.sh
104 Or to build and run only a specific subset, e.g. host advertising tests:
106 .. code-block:: bash
108 # Build the Bluetooth host advertising tests
109 ${ZEPHYR_BASE}/tests/bsim/bluetooth/host/adv/compile.sh
113 SEARCH_PATH=${ZEPHYR_BASE}/tests/bsim/bluetooth/host/adv \
114 ${ZEPHYR_BASE}/tests/bsim/run_parallel.sh
117 the tests in batch.
119 After building the tests' required binaries you can run a test directly using its individual test
122 For example you can build the required binaries for the networking tests with
124 .. code-block:: bash
126 WORK_DIR=${ZEPHYR_BASE}/bsim_out ${ZEPHYR_BASE}/tests/bsim/net/compile.sh
128 and then directly run one of the tests:
130 .. code-block:: bash
132 ${ZEPHYR_BASE}/tests/bsim/net/sockets/echo_test/tests_scripts/echo_test_802154.sh
138 ---------
140 See the :zephyr_file:`Bluetooth sample test <tests/bsim/bluetooth/host/misc/sample_test/README.rst>…
144 -------------
147 for the tests' scripts placed in the subfolders below.
152 To speed up compilation for users interested only in a subset of tests, several compile scripts
156 required, and some Zephyr users do not use or have west, but still use the build and tests scripts.
159 ------------
161 Please follow the existing conventions and do not design one-off bespoke runners (e.g. a python
164 The rationale is that it is easier and faster for the maintainers to perform tree-wide updates for
165 build system or compatibility changes if the tests are run in the same manner, with the same
174 building and running tests locally, debugging, etc..
178 - Each test is defined by a shell script with the extension ``.sh``, in a subfolder called
180 - It is recommended to run a single test per script file. It allows for better parallelization of
182 - Scripts expect that the binaries they require are already built. They should not compile binaries.
183 - Scripts will spawn the processes for every simulated device and the physical layer simulation.
184 - Scripts must return 0 to the invoking shell if the test passes, and not 0 if the test fails.
185 - Each test must have a unique simulation id, to enable running different tests in parallel.
186 - Neither the scripts nor the images should modify the workstation filesystem content beyond the
189 - Tests that require several consecutive simulations (e.g, if simulating a device pairing, powering
193 - Avoid overly long tests. If the test takes over 20 seconds of runtime, consider if it is possible
194 to split it in several separate tests.
195 - If the test takes over 5 seconds, set ``EXECUTE_TIMEOUT`` to a value that is at least 5 times
196 bigger than the measured run-time.
197 - Do not set ``EXECUTE_TIMEOUT`` to a value lower than the default.
198 - Tests should not be overly verbose: less than a hundred lines are expected on the outputs. Do make