DevHeads IoT Integration Server•2mo ago

First Contributions to Zephyr Approved for v4.1.0 – Happy to Chat About Testing and Development!

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

GitHub

tests: posix: common: separate into smaller testsuites · Issue #794...

Is your enhancement proposal related to a problem? Please describe. The posix.common testsuite contains a lot of mostly unrelated testsuites. As a result, the code size is large, but mostly the dat...

13 Replies

melta101•2mo ago

Amazing work

ZacckOsiemo•2mo ago

amazing, are these tests for the system? And can this be used for application testing.

32bitSaviour•2mo ago

The tests are for Zephyr system, its POSIX architecture to be exact.

ZacckOsiemo•2mo ago

Do application tests look the same as system tests

32bitSaviour•2mo ago

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.

ZacckOsiemo•2mo ago

im super keen to explore this structure.

32bitSaviour•2mo ago

The structure of a basic test resembles that of a basic application.

<test>
├── CMakeLists.txt
├── prj.conf
├── testcase.yaml
└── src
    └── main.c

<test>
├── CMakeLists.txt
├── prj.conf
├── testcase.yaml
└── src
    └── main.c

32bitSaviour•2mo ago

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>
    ├── module.cmake
    └── foo
        ├── CMakeLists.txt
        └── Kconfig
<app>
├── CMakeLists.txt
├── app.overlay
├── prj.conf
├── VERSION
└── src
    └── main.c
<module_tests>
├── CMakeLists.txt
├── prj.conf
├── testcase.yaml
└── src
    └── main.c

<module>
    ├── module.cmake
    └── foo
        ├── CMakeLists.txt
        └── Kconfig
<app>
├── CMakeLists.txt
├── app.overlay
├── prj.conf
├── VERSION
└── src
    └── main.c
<module_tests>
├── CMakeLists.txt
├── prj.conf
├── testcase.yaml
└── src
    └── main.c

ZacckOsiemo•2mo ago

what would your modules contain? And how close do the tests get to hardware?

32bitSaviour•2mo ago

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.

wafa_ath•2mo ago

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 😅

32bitSaviour•2mo ago

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.

wafa_ath•2mo ago

thnaks alot ! Good tip about POSIX too;

Gaming

Programming

First Contributions to Zephyr Approved for v4.1.0 – Happy to Chat About Testing and Development!

Did you find this page helpful?