Lines Matching +full:check +full:- +full:pr

78 Check :ref:`the page on coverage generation <coverage_posix>` for more info.
94 .. code-block:: bash
106 .. code-block:: bash
116 Check the ``run_parallel.sh`` help for more options and examples on how to use this script to run
124 .. code-block:: bash
130 .. code-block:: bash
138 ---------
144 -------------
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
168 If you have a good idea for improving your test script, please make a PR changing *all* the test
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
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