Searched +refs:test +refs:example (Results 1 – 25 of 275) sorted by relevance
1234567891011
| /Zephyr-latest/scripts/ci/es_upload/ |
| D | README.md | 5 script for [Twister](https://docs.zephyrproject.org/latest/develop/test/twister.html)
34 server with the appropriate map file, for example:
70 ### Twister test results
75 --index zephyr-test-example \
79 Upload Twister test results 'as-is', without additional transformations:
82 --index zephyr-test-example \
89 Store test results with `recording` data entries, for example from
91 test suite.
96 --index zephyr-test-recording-example-1 \
100 Upload data with 'flattened' test suites creating documents for each `recording` data entry.
[all …]
|
| /Zephyr-latest/doc/develop/test/ |
| D | twister.rst | 6 Twister scans for the set of test applications in the git repository
7 and attempts to execute them. By default, it tries to build each test
10 The default options will build the majority of the test applications on a
14 Because of the limited test execution coverage, twister
21 shows for every test application how the test is run (qemu, native_sim, etc.) or
24 of a test is likewise reported in the ``twister.json`` and other report files.
25 There are a few reasons why twister only builds a test and doesn't run it:
27 - The test is marked as ``build_only: true`` in its ``.yaml``
29 - The test configuration has defined a ``harness`` but you don't have
72 a simulated (for example QEMU) environment.
[all …]
|
| D | ztest.rst | 8 test structure.
13 Creating a test suite
16 Using Ztest to create a test suite is as easy as calling the :c:macro:`ZTEST_SUITE`. The macro
21 test will run. The predicate will get a pointer to the global state passed in through
23 * :c:type:`ztest_suite_setup_t` - An optional setup function which returns a test fixture. This
24 will be called and run once per test suite run.
26 test in this suite.
28 test in this suite.
32 Below is an example of a test suite using a predicate:
49 There are 5 macros used to add a test to a suite, they are:
[all …]
|
| D | pytest.rst | 3 Integration with pytest test framework
30 Pytest-based test suites are discovered the same way as other twister tests, i.e., by a presence
31 of test/sample.yaml. Inside, a keyword ``harness`` tells twister how to handle a given test.
32 In the case of ``harness: pytest``, most of twister workflow (test suites discovery,
41 If ``harness: pytest`` is used, twister delegates the test execution to pytest, by calling it as
44 sets the test result accordingly.
46 How to create a pytest test
49 An example folder containing a pytest test, application source code and Twister configuration .yaml
63 An example of a pytest test is given at
72 some.foo.test:
[all …]
|
| D | coverage.rst | 7 the code are covered by a given test or application.
20 `GCC GCOV <gcov_>`_ is a test coverage program
21 used together with the GCC compiler to analyze and create test coverage reports
33 device and the second to enable in the test application. As explained earlier the
35 device has enough RAM when enabling the coverage for it. For example a small device
36 like frdm_k64f can run a simple test application but the more complex test
42 To report the coverage for the particular test application set :kconfig:option:`CONFIG_COVERAGE`.
114 You may postprocess these with your preferred tools. For example:
145 For example, you may invoke:
166 command line option, for example:
|
| /Zephyr-latest/samples/boards/nxp/adsp/number_crunching/ |
| D | README.rst | 10 This example demonstrates how to include a proprietary static library into the Zephyr build system.
64 An output example, for CMSIS-DSP is:
70 Proprietary library example!
72 [Library Test] == Vector Sum test ==
75 [Library Test] == Vector Sum test end with 1 ==
77 [Library Test] == Vector power sum test ==
80 [Library Test] == Vector power sum test end with 1 ==
82 [Library Test] == Vector power sum test ==
85 [Library Test] == Vector power sum test end ==
87 [Library Test] == Fast Fourier Transform on Real Data test ==
[all …]
|
| /Zephyr-latest/doc/develop/test/twister/ |
| D | twister_blackbox.rst | 6 This guide aims to explain the structure of a test file so the reader will be able
16 Auxiliary test data follows whichever format it was in originally.
23 Sample test file
38 --test-config $TEST_DATA/test_config.yaml -p qemu_x86 -p frdm_k64f
42 Such a test provides us with all the outputs we typically expect of a Twister run thanks to
49 with ``--outdir`` flag (L52) to keep test-generated files in temporary directories.
63 - this is an example of ``pytest`` 's test parametrization.
64 …d up on it `here <https://docs.pytest.org/en/7.1.x/example/parametrize.html#different-options-for-…
80 consider whether they will be used in just one test file, or in many.
86 take a look there for an example.
[all …]
|
| /Zephyr-latest/tests/drivers/build_all/sensor/ |
| D | Kconfig | 8 Enables building and running the generic sensor test suite that will
13 int "Number of expected values to use in test"
18 test, interpolated from the sensor's reported lower and upper sample
19 range boundaries. The test will run one iteration for each expected
20 value. For example, if GENERIC_TEST_NUM_EXPECTED_VALS == 5, and the
21 sensor range is 0..100, the test will run 5 times with expected values
|
| /Zephyr-latest/samples/shields/npm6001_ek/doc/ |
| D | index.rst | 9 This sample is provided as an example to test the :ref:`npm6001_ek`. The sample
10 provides a shell interface that allows to test multiple functionalities offered
21 Below you can find a wiring example for the nRF52840 DK:
24 :alt: nRF52840DK + nPM6001-EK wiring example
27 nRF52840DK + nPM6001-EK wiring example
32 The sample is designed so that it can run on any platform. For example, when
43 provided to test the PMIC. Below you can find details for each subcommand.
48 The ``npm6001`` shell interface provides the ``regulator`` subcommand to test
116 The ``npm6001`` shell interface provides the ``gpio`` subcommand to test the
157 The ``npm6001`` shell interface provides the ``wdt`` subcommand to test the
|
| /Zephyr-latest/tests/drivers/pwm/pwm_gpio_loopback/ |
| D | Kconfig | 4 mainmenu "PWM GPIO loopback test"
27 Maximum allowed deviation (%) from the programmed values for the test to be
28 considered a PASS. For example, if set to 5, the measured period or duty cycle
29 can deviate by up to 5% from the programmed values for the test to pass.
|
| /Zephyr-latest/tests/bluetooth/classic/sdp_c/ |
| D | README.rst | 9 This test suite uses ``bumble`` for testing Bluetooth Classic communication between a host
10 PC (running :ref:`Twister <twister_script>`) and a device under test (DUT) running Zephyr.
15 The test suite has the following prerequisites:
27 ``--hci-transport`` test suite argument (i.e. run ``twister`` with the
37 Running the test suite on :ref:`mimxrt1170_evk` relies on configuration of ``bumble``.
42 For example, on windows, a PTS dongle is used. After `WinUSB driver`_ has been installed,
45 If the HCI transport is ``usb:0`` and debug console port is ``COM4``, the test suite can be
55 Running the test suite on hardware requires a HCI transport connected to the host PC.
57 The test suite can be launched using Twister. Below is an example for running on the
|
| /Zephyr-latest/tests/kernel/timer/starve/ |
| D | README.txt | 1 Title: Timer Starvation test
3 The purpose of the test is to detect whether the timer implementation
11 This test is not run in automatic test suites because it generally takes
13 and the tick rate. By default the test passes if one hour passes
20 For example a system that uses a 32768-Hz internal timer counter with
|
| /Zephyr-latest/tests/bsim/bluetooth/host/misc/sample_test/ |
| D | CMakeLists.txt | 25 # List every source file in the test application. Do not use GLOB.
27 # It is a good idea to have one file per test role / entry point.
29 # Try to keep test procedures readable, that is minimizing the amount of
30 # boilerplate. Use the `testlib` for anything that is not the object of the test
31 # or that you don't need tight control over. For example, setting up a
35 # the test and should be in the same file as the test entry point. Any other
40 # characteristic UUIDs, test data that should be verified by both parties,
43 # Ideally, main.c should only set up the test framework, and map the entry
44 # points to the test identifiers.
|
| /Zephyr-latest/boards/segger/trb_stm32f407/doc/ |
| D | index.rst | 8 ARM Cortex-M4 CPU, to test hardware tracing with the SEGGER Trace-Pro
73 The SEGGER-TRB-STM32F407 board is specially designed to test the SEGGER
74 Trace-Pro debuggers, so this example assumes a J-Trace or J-Link is used.
82 Here is an example for the :zephyr:code-sample:`blinky` application.
94 Here is an example for the :zephyr:code-sample:`blinky` application.
|
| /Zephyr-latest/doc/connectivity/bluetooth/shell/host/ |
| D | gatt.rst | 9 On the server side, you can register pre-defined test services using the :code:`gatt register`
13 You can now subscribe to those new services on the client side. Here is an example on how to
14 subscribe to the test service:
|
| /Zephyr-latest/boards/shields/npm1300_ek/doc/ |
| D | index.rst | 9 The nPM1300 EK lets you test different functions and features of the nPM1300
17 Arduino shield connectors. For example, the I2C lines need to be connected to
|
| /Zephyr-latest/samples/subsys/usb/audio/headphones_microphone/ |
| D | README.rst | 29 Steps to test the sample:
34 - Start streaming audio (for example by playing an audio file on the HOST).
35 - Start recording audio stream (for example using Audacity).
|
| /Zephyr-latest/samples/subsys/usb/audio/headset/ |
| D | README.rst | 28 Steps to test the sample:
33 - Start streaming audio (for example by playing an audio file on the HOST).
34 - Start recording audio stream (for example using Audacity).
|
| /Zephyr-latest/tests/drivers/watchdog/wdt_error_cases/ |
| D | README.txt | 1 This test suite contains negative test cases for the Watchdog driver.
10 both error code and assertion fail set test result as passed.
11 See for example test_02_wdt_setup_before_setting_timeouts where
15 These tests were written to increase test coverage for the Watchdog driver.
17 Therefore, in all test cases watchdog shall NOT expire.
23 each test name with f.e. 'test_08b_...'.
30 Follow these guidelines when enabling test execution on a new target.
35 Every test assumes that watchdog is disabled at startup.
36 As a result, executing this test suite on a target that doesn't
54 This define will be used in wdt_install_timeout() "correct" test step.
[all …]
|
| /Zephyr-latest/doc/hardware/emulator/ |
| D | bus_emulators.rst | 13 various subsystems. For example, it is possible to write an emulator
17 Emulators often implement special features for testing. For example a
34 Below that are peripheral drivers, such as the AT24 EEPROM driver. We can test
39 Separately we can test the STM32 and NXP I2C drivers on real hardware using API
43 Putting the two together, we can test the application and peripheral code
48 Using the above framework we can test an entire application (e.g. Embedded
56 * Ensure 100% test coverage for drivers (green)
101 :alt: Device class example, demonstrating BC1.2 charging detectors.
121 Example test flow:
128 With this architecture, the same test can be used will all supported drivers in
[all …]
|
| /Zephyr-latest/samples/boards/espressif/spiram_test/ |
| D | README.rst | 41 This example uses ``west espressif monitor``, which automatically detects the serial
51 SPIRAM mem test pass
52 Internal mem test pass
|
| /Zephyr-latest/tests/kernel/common/ |
| D | multilib.txt | 8 (for example, ARM Cortex-M requires thumb2 multilib and will be broken with
9 default ("arm") multilib or "thumb" multilib). This app is a smoke-test
|
| /Zephyr-latest/samples/tfm_integration/tfm_regression_test/ |
| D | README.rst | 11 The build system will replace the Zephyr application with the Non-Secure TF-M test application,
33 Following is an example based on ``west build``
46 #### Execute test suites for the Secure area ####
63 *** Secure test suites summary ***
72 Test suite 'IPC secure interface test (TFM_IPC_TEST_1XXX)' has PASSED
74 *** End of Secure test suites ***
76 #### Execute test suites for the Non-secure area ####
106 *** Non-secure test suites summary ***
109 Test suite 'Crypto non-secure interface test (TFM_CRYPTO_TEST_6XXX)' has PASSED
112 Test suite 'QCBOR regression test(TFM_QCBOR_TEST_7XXX)' has PASSED
[all …]
|
| /Zephyr-latest/samples/shields/x_nucleo_iks4a1/sensorhub1/ |
| D | README.rst | 8 This sample is provided as an example to test the X-NUCLEO-IKS4A1 shield
32 Arduino connector. For this example, we use a :zephyr:board:`nucleo_f411re` board.
|
| /Zephyr-latest/samples/shields/x_nucleo_iks4a1/sensorhub2/ |
| D | README.rst | 8 This sample is provided as an example to test the X-NUCLEO-IKS4A1 shield
32 Arduino connector. For this example, we use a :zephyr:board:`nucleo_f411re` board.
|
1234567891011
