From 7495a092ad564648977fb56958adffa4d98a62d7 Mon Sep 17 00:00:00 2001 From: MarkoSagadin Date: Tue, 19 Mar 2024 13:10:09 +0100 Subject: [PATCH] docs: update checklist in README.md --- .github/pull_request_template.md | 7 +- README.md | 130 +++++++++--------- boards/arm/custom_nrf52840dk/README.md | 10 +- samples/renode_example/README.md | 51 +++---- .../renode_example/renode/STTS751/README.md | 14 +- scripts/rpi-jlink-server/README.md | 44 +++--- tests/README.md | 96 ++++++------- 7 files changed, 165 insertions(+), 187 deletions(-) diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md index 1b5040f..1734261 100644 --- a/.github/pull_request_template.md +++ b/.github/pull_request_template.md @@ -19,12 +19,11 @@ write why --> - [ ] My code follows the [style guidelines] as defined by IRNAS. - [ ] I have performed a self-review of my code. - [ ] My changes generate no new warnings. -- [ ] I added/updated source code documentation for all newly added or changed - functions. +- [ ] I added/updated source code documentation for all newly added or changed functions. - [ ] I updated all customer-facing technical documentation. -Example strikeout: - [x] ~~I updated all customer-facing technical -documentation.~~ - This PR introduced only internal facing changes. +Example strikeout: - [x] ~~I updated all customer-facing technical documentation.~~ - This PR +introduced only internal facing changes. ## After-review steps diff --git a/README.md b/README.md index 4bc62ad..3b2b476 100644 --- a/README.md +++ b/README.md @@ -6,34 +6,40 @@ of CI workflows for release automation. ## Checklist -- [ ] Provide a concise and accurate description of your project in the GitHub - "description" field. -- [ ] Provide a concise and accurate description of your project in this - `README.md` file, replace the title. +### General GitHub setup + +- [ ] Provide a concise and accurate description of your project in the GitHub "description" field. +- [ ] Provide a concise and accurate description of your project in this `README.md` file, replace + the title. - [ ] Ensure that your project follows [repository naming scheme]. -- [ ] Turn on `gitlint` tool by running `gitlint install-hook`. If you do not - have it yet, follow instructions - [here](https://github.com/IRNAS/irnas-guidelines-docs/tree/main/tools/gitlint). -- [ ] Select the version of NCS in the `west.yaml` file, check the below section - for specifics. -- [ ] Provide repository setup instructions, use template in _Setup_ section - below. Replace ``, ``, and `` as - appropriate for your project. -- [ ] Set required [GitHub Actions secrets]. You can also **contact person in - charge for this** to do it for you. -- [ ] Create a new project on the CodeChecker server. You can also **contact - person in charge** to do it for you. -- [ ] (Optional) Include the `twister-rpi.yaml` GitHub Actions workflow for the - on-target testing. To do this copy the workflow from the [Twister RPi - workflow] into this project and see it's [README.md] in this repo for more - information on the requirements and setup. -- [ ] Remove any files and folders that your project doesn't require. This avoid - possible multiple definition issues down the road and keeps your project - clean from redundant files. -- [ ] Ensure that all rule targets provided in the example makefile work and are - relevant for your project. Change them or remove them, if you need to. If - you remove them make sure that they are not called from the enabled - workflows. + +### Tooling + +- [ ] Turn on `pre-commit` tool by running `pre-commit install`. If you do not have it yet, follow + instructions + [here](https://github.com/IRNAS/irnas-guidelines-docs/tree/main/tools/pre-commit). + +### Zephyr specifics + +- [ ] Select the version of NCS in the `west.yaml` file, check the below section for specifics. +- [ ] Provide repository setup instructions, use template in _Setup_ section below. Replace + ``, ``, and `` as appropriate for your project. + +### GitHub Actions + +- [ ] Set required [GitHub Actions secrets]. +- [ ] Create a new project on the [CodeChecker server]. +- [ ] Ensure that all rule targets provided in the example makefile work and are relevant for your + project. Change them or remove them, if you need to. If you remove them make sure that they + are not called from the enabled workflows. +- [ ] (Optional) Include the `twister-rpi.yaml` GitHub Actions workflow for the on-target testing. + To do this copy the workflow from the [Twister RPi workflow] into this project and see it's + [README.md] in this repo for more information on the requirements and setup. + +### Cleanup + +- [ ] Remove any files and folders that your project doesn't require. This avoid possible multiple + definition issues down the road and keeps your project clean from redundant files. - [ ] As a final step delete this checklist and commit changes. [repository naming scheme]: @@ -43,6 +49,8 @@ of CI workflows for release automation. [README.md]: scripts/rpi-jlink-server/README.md [Twister RPi workflow]: https://github.com/IRNAS/irnas-workflows-software/tree/main/workflow-templates/rpi-twister-hil +[CodeChecker server]: + https://github.com/IRNAS/irnas-codechecker-software?tab=readme-ov-file#creating-new-products---codechecker-integration-in-east ## Setup @@ -66,6 +74,11 @@ east install toolchain east update ``` +### Setup `pre-commit` + +Turn on `pre-commit` tool by running `pre-commit install`. If you do not have it yet, follow +instructions [here](https://github.com/IRNAS/irnas-guidelines-docs/tree/main/tools/pre-commit). + ## Building and flashing To build the application firmware: @@ -93,49 +106,42 @@ east util rtt ## west.yaml and name-allowlist -The manifest file (`west.yaml`) that comes with this template by default only -allows certain modules from Nordic's `sdk-nrf` and `sdk-zephyr` repositories, -while ignoring/blocking others. +The manifest file (`west.yaml`) that comes with this template by default only allows certain modules +from Nordic's `sdk-nrf` and `sdk-zephyr` repositories, while ignoring/blocking others. -This means that a setup on the new machine and in CI is faster as the -`west update` command does not clone all modules from the mentioned repositories -but only the ones that are needed. +This means that a setup on the new machine and in CI is faster as the `west update` command does not +clone all modules from the mentioned repositories but only the ones that are needed. -Manifest file only allows modules that are commonly used by IRNAS, however this -can be easily changed by uncommenting the required modules and running -`west update`. +Manifest file only allows modules that are commonly used by IRNAS, however this can be easily +changed by uncommenting the required modules and running `west update`. -**IMPORTANT:** Such improvements do not come with some tradeoffs, there are now -two things that a developer must take note of. +**IMPORTANT:** Such improvements do not come with some tradeoffs, there are now two things that a +developer must take note of. ### Compile time errors cause of blocked/missing headers -If the application source code includes some headers from blocked/missing -modules or if included headers use blocked/missing modules you will get an error -that will complain about missing header files. In that case, you have to go to -manifest file, find commented module, run `west update`, return to the app -folder, delete build folder and build again. +If the application source code includes some headers from blocked/missing modules or if included +headers use blocked/missing modules you will get an error that will complain about missing header +files. In that case, you have to go to manifest file, find commented module, run `west update`, +return to the app folder, delete build folder and build again. ### Updating `sdk-nrf` version -Whenever you want to update the version of `sdk-nrf` (also know simply as `NCS`) -you need to keep one general thing in mind: you need to manually keep revisions -of `sdk-nrf` and `sdk-zephyr` projects, as well as their imports in sync. - -1. Open `west.yml` file in `sdk-nrf` repository - ([link](https://github.com/nrfconnect/sdk-nrf)). Make sure that you select - correct tag from selection from top-left dropdown menu. -2. Check what repos are under `sdk-zepyhr` project's `name-allowlist`, those - should match the repos in `west.yaml` of your project (and this template), - under `sdk-zepyhr` project's `name-allowlist`. Most of the time they should - be commented out, but depends. -3. Check what other repositories appear under `sdk-zepyhr` project as standalone - projects, they start appearing around line 100, after `NCS repositories` - comment. This projects should match the repos in `west.yaml` of your project - (and this template), under `sdk-nrf` project's `name-allowlist`. Most of the - time they should be commented out, but again, this depends. - -When a new `sdk-nrf` version is released, some new repos as `NCS repositories` -might appear or be moved into `sdk-zephyr`. +Whenever you want to update the version of `sdk-nrf` (also know simply as `NCS`) you need to keep +one general thing in mind: you need to manually keep revisions of `sdk-nrf` and `sdk-zephyr` +projects, as well as their imports in sync. + +1. Open `west.yml` file in `sdk-nrf` repository ([link](https://github.com/nrfconnect/sdk-nrf)). + Make sure that you select correct tag from selection from top-left dropdown menu. +2. Check what repos are under `sdk-zepyhr` project's `name-allowlist`, those should match the repos + in `west.yaml` of your project (and this template), under `sdk-zepyhr` project's + `name-allowlist`. Most of the time they should be commented out, but depends. +3. Check what other repositories appear under `sdk-zepyhr` project as standalone projects, they + start appearing around line 100, after `NCS repositories` comment. This projects should match the + repos in `west.yaml` of your project (and this template), under `sdk-nrf` project's + `name-allowlist`. Most of the time they should be commented out, but again, this depends. + +When a new `sdk-nrf` version is released, some new repos as `NCS repositories` might appear or be +moved into `sdk-zephyr`. After any change to the `west.yaml` do not forget to run `west update`. diff --git a/boards/arm/custom_nrf52840dk/README.md b/boards/arm/custom_nrf52840dk/README.md index 02e08a8..b6f1c7e 100644 --- a/boards/arm/custom_nrf52840dk/README.md +++ b/boards/arm/custom_nrf52840dk/README.md @@ -1,8 +1,8 @@ # Custom nRF52840 Board -`custom_nrf52840` board is used to demonstrate how to create custom boards. It -is in fact a simplified version of the nRF52840-DK board, so the `app` can be -run on that development kit when using `custom_nrf52840dk`. +`custom_nrf52840` board is used to demonstrate how to create custom boards. It is in fact a +simplified version of the nRF52840-DK board, so the `app` can be run on that development kit when +using `custom_nrf52840dk`. -Only speciality is that the jlink runner is used by default when using -`west flash`, this is set by `board.cmake` file. +Only speciality is that the jlink runner is used by default when using `west flash`, this is set by +`board.cmake` file. diff --git a/samples/renode_example/README.md b/samples/renode_example/README.md index e08386e..08e6cfe 100644 --- a/samples/renode_example/README.md +++ b/samples/renode_example/README.md @@ -1,26 +1,23 @@ # Renode Example -[Renode](https://renode.io/) is an open-source software development framework -with commercial support from Antmicro that lets you develop, debug and test -multi-node device systems reliably, scalably and effectively. +[Renode](https://renode.io/) is an open-source software development framework with commercial +support from Antmicro that lets you develop, debug and test multi-node device systems reliably, +scalably and effectively. -The goal of this sample is to review the Renode platform and how to use it with -the nrf52840dk board. +The goal of this sample is to review the Renode platform and how to use it with the nrf52840dk +board. -This sample contains a simple firmware for the nrf52840dk board, which does the -following: +This sample contains a simple firmware for the nrf52840dk board, which does the following: - On the press of Button 1 (on the nrf52840DK) it prints `GPIO Interrupt fired`. - It has enabled GPIO and Sensor shells. -- It specifies in its device tree LIS2DW12 accelerometer and STTS751 temperature - sensors. +- It specifies in its device tree LIS2DW12 accelerometer and STTS751 temperature sensors. ## Pre-Requisites ### Install Renode and Robot Framework -To install Renode and all its required dependencies use the below installation -script: +To install Renode and all its required dependencies use the below installation script: ```shell cd @@ -43,24 +40,20 @@ To run the built firmware in the Renode simulator just run: renode renode/nrf52840dk_example.resc ``` -The above command will open Renode GUI and load the provided script into it. At -the same time it will open another terminal window with uart communication. +The above command will open Renode GUI and load the provided script into it. At the same time it +will open another terminal window with uart communication. -Renode scripts [.resc] enable you to encapsulate repeatable elements of your -project (like creating a machine and loading a binary) to conveniently execute -them multiple times. +Renode scripts [.resc] enable you to encapsulate repeatable elements of your project (like creating +a machine and loading a binary) to conveniently execute them multiple times. -[.resc]: - https://renode.readthedocs.io/en/latest/introduction/using.html#resc-scripts +[.resc]: https://renode.readthedocs.io/en/latest/introduction/using.html#resc-scripts ## Robot Framework -Renode greatly -[integrates](https://renode.readthedocs.io/en/latest/introduction/testing.html) -with the `Robot Framework` test automation framework. For this sample, we have -created the `test-nrf52840dk.robot` file which will load the -`nrf52840dk_nrf52840.repl` file, load the created sample `zephyr.elf` firmware -file, start the machine and execute tests. The tests are defined in the +Renode greatly [integrates](https://renode.readthedocs.io/en/latest/introduction/testing.html) with +the `Robot Framework` test automation framework. For this sample, we have created the +`test-nrf52840dk.robot` file which will load the `nrf52840dk_nrf52840.repl` file, load the created +sample `zephyr.elf` firmware file, start the machine and execute tests. The tests are defined in the `test-nrf52840dk.robot` file. To run the tests: @@ -71,10 +64,9 @@ renode-test test-nrf52840dk.robot ## Caveats -We have implemented a simulated temperature driver in -`renode/STTS751/STTS751.cs`. During development, we discovered that the same -driver in the Zephyr kernel has a bug in the temperature conversion procedure -(see `stts751_temp_convert` function in `drivers/sensor/stts751/stts751.c`). +We have implemented a simulated temperature driver in `renode/STTS751/STTS751.cs`. During +development, we discovered that the same driver in the Zephyr kernel has a bug in the temperature +conversion procedure (see `stts751_temp_convert` function in `drivers/sensor/stts751/stts751.c`). This means that if we input the simulated temperature value with: @@ -82,8 +74,7 @@ This means that if we input the simulated temperature value with: sysbus.twi0.stts Temperature -5.5 ``` -will not get the expected response if we send the below shell command to the -firmware: +will not get the expected response if we send the below shell command to the firmware: ```renode uart:~$ sensors get stts751@4a ambient_temp diff --git a/samples/renode_example/renode/STTS751/README.md b/samples/renode_example/renode/STTS751/README.md index b8feef8..1659b84 100644 --- a/samples/renode_example/renode/STTS751/README.md +++ b/samples/renode_example/renode/STTS751/README.md @@ -1,7 +1,7 @@ # STTS751 -This document outlines the steps required to implement a custom peripheral for -Phenode. This chip is supported by Zephyr, but is not implemented in Renode. +This document outlines the steps required to implement a custom peripheral for Phenode. This chip is +supported by Zephyr, but is not implemented in Renode. Useful inks: @@ -14,10 +14,8 @@ Observations during the implementation process: 1. Add I2C device to .overlay file - driver must be supported in Zephyr 2. Add sensor to `.repl` file, using the same address as in `.overlay` file -3. Add Sensor implementation to `STTS751.cs` (this file). There are several ways - to implement the sensor. We have followed the example of `LIS2DW12.cs`. - Several methods must be implemented, this depends on the class the sensor - inherits from. -4. Include the `STTS751.cs` sensor in the `.resc` file using the `include` - syntax +3. Add Sensor implementation to `STTS751.cs` (this file). There are several ways to implement the + sensor. We have followed the example of `LIS2DW12.cs`. Several methods must be implemented, this + depends on the class the sensor inherits from. +4. Include the `STTS751.cs` sensor in the `.resc` file using the `include` syntax 5. Add a simple test to the `.robot` file diff --git a/scripts/rpi-jlink-server/README.md b/scripts/rpi-jlink-server/README.md index 69532ad..01cb757 100644 --- a/scripts/rpi-jlink-server/README.md +++ b/scripts/rpi-jlink-server/README.md @@ -1,33 +1,32 @@ # Raspberry Pi J-Link Server -This directory contains two scripts that are used to run tests on a remote -Raspberry Pi, which is connected to a J-Link debugger: +This directory contains two scripts that are used to run tests on a remote Raspberry Pi, which is +connected to a J-Link debugger: -- The `request_resource.sh` script, which should be used inside a GitHub Action - Workflow before and after running tests on the device. -- The `twister_pty.py` script, which is used with the `west/east twister` - command. This script receives and prints the outputs generated by the device. +- The `request_resource.sh` script, which should be used inside a GitHub Action Workflow before and + after running tests on the device. +- The `twister_pty.py` script, which is used with the `west/east twister` command. This script + receives and prints the outputs generated by the device. ## Remote Raspberry Pi -Documentation on how to set up the Raspberry Pi and a detailed explanation of -the functionality can be found +Documentation on how to set up the Raspberry Pi and a detailed explanation of the functionality can +be found [here](https://github.com/IRNAS/irnas-runners-software/blob/main/rpi-jlink-server/README.md). ## GitHub Actions Workflow -The scripts mentioned are used by the `twister-rpi.yaml` GitHub Actions -Workflow. The workflow is not included in this repository, as it is opt-in. To -include it, you must copy the `twister-rpi.yaml` from the +The scripts mentioned are used by the `twister-rpi.yaml` GitHub Actions Workflow. The workflow is +not included in this repository, as it is opt-in. To include it, you must copy the +`twister-rpi.yaml` from the [linked repository](https://github.com/IRNAS/irnas-workflows-software/blob/main/workflow-templates/rpi-twister-hil/.github/twister-rpi.yaml) -into `.github/workflows` folder inside your repository and add the following -GitHub secrets: +into `.github/workflows` folder inside your repository and add the following GitHub secrets: - RPI_IP - IP address of the Raspberry Pi running the JLinkRemoteServer. -The IP can be the local IP address of the Raspberry Pi, if the GitHub Action -runner is running on the same network. Or it has to be the VPN IP address of the -Raspberry Pi, if the GitHub Action runner is running on a different network. +The IP can be the local IP address of the Raspberry Pi, if the GitHub Action runner is running on +the same network. Or it has to be the VPN IP address of the Raspberry Pi, if the GitHub Action +runner is running on a different network. The following make command has been added to the projects `makefile`: @@ -36,15 +35,14 @@ test-remote: east twister -T tests -p nrf52840dk_nrf52840 --device-testing --device-serial-pty="scripts/twister_pty.py --host ${RPI_IP} --port 7777" --west-runner=jlink --west-flash="--tool-opt=ip ${RPI_IP}:7778" ``` -The command is used to run twister tests on the remote device. The -`--device-serial-pty` and `--west-flash` options are used to connect to the -remote device. The `twister_pty.py` script is used to print the output of the -device to the GitHub Actions log. The `--west-runner` and `--west-flash` options -are used to flash the device with the firmware and run the tests. +The command is used to run twister tests on the remote device. The `--device-serial-pty` and +`--west-flash` options are used to connect to the remote device. The `twister_pty.py` script is used +to print the output of the device to the GitHub Actions log. The `--west-runner` and `--west-flash` +options are used to flash the device with the firmware and run the tests. **IMPORTANT: The `testcase.yaml` has been modified as well to include the `- CONFIG_NULL_POINTER_EXCEPTION_DETECTION_NONE=y` `extra_configs` option.** This flag fixes the tests taking a minute longer, due to a timeout. -[This related issue](https://github.com/zephyrproject-rtos/zephyr/issues/39216) -describes the problem. +[This related issue](https://github.com/zephyrproject-rtos/zephyr/issues/39216) describes the +problem. diff --git a/tests/README.md b/tests/README.md index a356402..3447062 100644 --- a/tests/README.md +++ b/tests/README.md @@ -1,17 +1,17 @@ # Tests -This document contains relevant instructions on how to use Zephyr's unit testing -framework Ztest and test runner Twister. +This document contains relevant instructions on how to use Zephyr's unit testing framework Ztest and +test runner Twister. -As Zephyr already provides great documentation on this [topic], this document -will only provide basic instructions, working examples and tips and tricks. +As Zephyr already provides great documentation on this [topic], this document will only provide +basic instructions, working examples and tips and tricks. [topic]: https://docs.zephyrproject.org/latest/develop/test/index.html ## Quick start with the `sample_test` project -`sample_test` project found in `tests` directory provides some examples on how -to use Ztest framework to test a trivial example library with unit tests. +`sample_test` project found in `tests` directory provides some examples on how to use Ztest +framework to test a trivial example library with unit tests. ### Running unit tests on host @@ -56,15 +56,14 @@ east build -b native_posix ./build/zephyr/zephyr.elf ``` -The created `zephyr.elf` file is just a normal Linux executable. To debug it -with `gdb` you can run: +The created `zephyr.elf` file is just a normal Linux executable. To debug it with `gdb` you can run: ```code gdb build/zephyr/zephyr.elf ``` -While debugging you will probably want to enable below two Kconfig symbols in -the `prj.conf` for better debugging experience: +While debugging you will probably want to enable below two Kconfig symbols in the `prj.conf` for +better debugging experience: ```Kconfig # Compiler optimizations will be set to -Og independently of other options. @@ -90,13 +89,12 @@ To see the serial output: minicom -D /dev/ttyACM0 ``` -Note: The exact path will wary, check for the board with `ls -al /dev/tty*` -command. +Note: The exact path will wary, check for the board with `ls -al /dev/tty*` command. ## Writing unit tests with Ztest -Again, the ultimate source of truth is the [Zephyr's Ztest] documentation. Some -basic explanation follows. +Again, the ultimate source of truth is the [Zephyr's Ztest] documentation. Some basic explanation +follows. [zephyr's ztest]: https://docs.zephyrproject.org/latest/develop/test/ztest.html @@ -114,39 +112,33 @@ ZTEST(my_test_suite, simple_equality) } ``` -- Each unit test needs to be placed inside the `ZTEST` macro. First argument is - `suit_name`, second is the `test_name`. `test_name` must start with `test_` - prefix so it can be picked up by Twister. -- Multiple tests can use the same `suit_name`, but need to have different - `test_name`. -- Various `zassert_*` [assertions] can then be used to check the equality if the - condition is true, false, etc. The common theme is that they all can take a - message with arguments in the end (just like `printf`), which is printed if an - assert fails. -- A suite of tests can have common setup, teardown, etc. functions to decrease - boilerplate code. See [Creating a test suite] section for more info. +- Each unit test needs to be placed inside the `ZTEST` macro. First argument is `suit_name`, second + is the `test_name`. `test_name` must start with `test_` prefix so it can be picked up by Twister. +- Multiple tests can use the same `suit_name`, but need to have different `test_name`. +- Various `zassert_*` [assertions] can then be used to check the equality if the condition is true, + false, etc. The common theme is that they all can take a message with arguments in the end (just + like `printf`), which is printed if an assert fails. +- A suite of tests can have common setup, teardown, etc. functions to decrease boilerplate code. See + [Creating a test suite] section for more info. See [zephyr/tests/ztest/base](https://github.com/zephyrproject-rtos/zephyr/tree/main/tests/ztest/base) for some basic usecases of Ztest framework. -[assertions]: - https://docs.zephyrproject.org/latest/develop/test/ztest.html#assertions +[assertions]: https://docs.zephyrproject.org/latest/develop/test/ztest.html#assertions [creating a test suite]: https://docs.zephyrproject.org/latest/develop/test/ztest.html#creating-a-test-suite ## Twister -Twister is a script that scans for the set of unit test applications in the git -repository and attempts to execute them. For listed boards, it can build the -applications, run them, check if they every successful and generate a report. +Twister is a script that scans for the set of unit test applications in the git repository and +attempts to execute them. For listed boards, it can build the applications, run them, check if they +every successful and generate a report. -Due to the number of features that it has it can take some time to figure out -how to do something that you want, see east twister `--extra-help` for the -supported options. +Due to the number of features that it has it can take some time to figure out how to do something +that you want, see east twister `--extra-help` for the supported options. -Also, see -[Zephyr's documentation](https://docs.zephyrproject.org/latest/develop/test/twister.html) +Also, see [Zephyr's documentation](https://docs.zephyrproject.org/latest/develop/test/twister.html) for more info. ### Simple example @@ -157,11 +149,10 @@ From the project's root directory run: east twister -p native_posix -T tests ``` -Twister will detect all projects with `testcase.yaml` in their project root -under `tests` directory and execute them. +Twister will detect all projects with `testcase.yaml` in their project root under `tests` directory +and execute them. -To run the same thing on the target you need to provide more info to the -Twister: +To run the same thing on the target you need to provide more info to the Twister: ```shell east twister -T tests -p nrf52dk_nrf52832 --device-testing --device-serial /dev/ttyACM0 @@ -171,37 +162,32 @@ Check the output for the results. ### `twister-out` folder -With every invocation of the `east twister` a `twister-out` folder is created. -It contains all build folders of the created projects, as well as the report -files. +With every invocation of the `east twister` a `twister-out` folder is created. It contains all build +folders of the created projects, as well as the report files. -Keep in mind, if you keep running `east twister` command and not deleting the -`twister-out` folder, then the command will rename it to `twister-out.X` (Where -`X` is a unique ascending number, starting with 1) before running the full -build. +Keep in mind, if you keep running `east twister` command and not deleting the `twister-out` folder, +then the command will rename it to `twister-out.X` (Where `X` is a unique ascending number, starting +with 1) before running the full build. ### `testcase.yaml` file -`testcase.yaml` file marks that a Twister should pick up the test folder and -build it. Its content defines for which platforms it should be built and tested. +`testcase.yaml` file marks that a Twister should pick up the test folder and build it. Its content +defines for which platforms it should be built and tested. See [Test Cases] section for more info. -[test cases]: - https://docs.zephyrproject.org/latest/develop/test/twister.html#test-cases +[test cases]: https://docs.zephyrproject.org/latest/develop/test/twister.html#test-cases ### Coverage report -Twister supports creating coverage reports from test runs with `gcovr` tool. -Adding extra flags to the command invocation creates a html file (among others) -which shows code coverage for each file. +Twister supports creating coverage reports from test runs with `gcovr` tool. Adding extra flags to +the command invocation creates a html file (among others) which shows code coverage for each file. ```shell east twister -T tests -p native_posix --coverage --coverage-tool gcovr ``` -Note that you might need to change `--coverage-basedir` or add new ones for your -project. +Note that you might need to change `--coverage-basedir` or add new ones for your project. To open the coverage report in the browser: