New DevHeads get a 320-point leaderboard boost when joining the DevHeads IoT Integration Community. In addition to learning and advising, active community leaders are rewarded with community recognition and free tech stuff. Start your Legendary Collaboration now!
Hey @here.
Happy to announce that I have managed to complete my first contributions(s) to Zephyr and most of them have been approved and marked for `v4.1.0`. It was a lot of learning around the Zephyr POSIX architecture, but seeing things actually go through is amazing. If you wanna talk testing or zephyr, I happy to chat.
All the issue are linked in this main issue https://github.com/zephyrproject-rtos/zephyr/issues/79454
Browse other questions tagged
Amazing work
amazing, are these tests for the system? And can this be used for application testing.
The tests are for Zephyr system, its POSIX architecture to be exact.
Do application tests look the same as system tests
Yes but mostly depends on how you have structured the application.
`ZTEST` the Zephyr library that is used for testing, is designed in a way that is allows (if you want to test your application) you to design your code in such a way that it is easily testable (think modules). A tightly coupled application is not easily testable.
ZTEST ends up generating a “main” function for each testsuite that runs all the tests.
im super keen to explore this structure.
The structure of a basic test resembles that of a basic application.
“`
├── CMakeLists.txt
├── prj.conf
├── testcase.yaml
└── src
└── main.c“`
An approach to this would be to have a test directory inside your app that tests functionality that you have declared as a module
“`
├── module.cmake
└── foo
├── CMakeLists.txt
└── Kconfig
├── CMakeLists.txt
├── app.overlay
├── prj.conf
├── VERSION
└── src
└── main.c
├── CMakeLists.txt
├── prj.conf
├── testcase.yaml
└── src
└── main.c
“`
what would your modules contain? And how close do the tests get to hardware?
Zephyr allow you to test as close to hardware as you want. It even has `BabbleSim` to allow you test radio activity in a simulator by producing a Linux executable that will connect to a physical simulator to test radio protocols like BLE.
On the other hand if you have software features you can use `native_sim` (this is possible because of Zephyr’s POSIX architecture) to test those.
Hardware testing is so neat you can even test on boards that are not yet supported by Zephyr just provide the soc, board and dts root directories to its test runner, `twister`.
for somone is new to zephyr and just knows the basics , what do u recommend to star with to get into it ,and Were there specific guidelines in Zephyr you followed, or was it more about adapting to the POSIX architecture requirements? , i know it’s alot of qst , am just intersted 😅
No worries.
Easiest way I found was to start out by building sample applications, flashing them on to a board to get a taste of the tooling.
Building something around a sample application, changing things, adding functionality from there you can move on to build something you want.
It can be painful but rewarding. As for specific guidelines to follow, I found the docs very informative. Though there are cases where things are missing and that gets tricky. You may have to figure things out by looking at issue comments and asking around; most of those missing things live in people’s brains. 😆
The specific issues I was handling were more of testing for the POSIX architecture, I had to beware that Zephyr does not try to implement the whole POSIX OS abstraction and the Zephyr docs were instrumental in keeping aware of what is implemented and what is not.
thnaks alot ! Good tip about POSIX too;
CONTRIBUTE TO THIS THREAD