DevHeads IoT Integration Server•13mo 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

v4.1.0

v4.1.0

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...

melta101APP•12/21/24, 3:34 PM

Amazing work

ZacckOsiemoAPP•12/21/24, 3:34 PM

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

32bitSaviourAPP•12/21/24, 3:35 PM

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

ZacckOsiemoAPP•12/21/24, 3:35 PM

Do application tests look the same as system tests

32bitSaviourAPP•12/21/24, 3:36 PM

Yes but mostly depends on how you have structured the application.
ZTESTZTEST 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.

ZacckOsiemoAPP•12/21/24, 3:36 PM

im super keen to explore this structure.

32bitSaviourAPP•12/21/24, 3:36 PM

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

32bitSaviourAPP•12/21/24, 3:36 PM

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

ZacckOsiemoAPP•12/21/24, 3:37 PM

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

32bitSaviourAPP•12/21/24, 3:37 PM

Zephyr allow you to test as close to hardware as you want. It even has BabbleSimBabbleSim 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_simnative_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, twistertwister.

wafa_athAPP•12/21/24, 3:37 PM

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

32bitSaviourAPP•12/21/24, 3:37 PM

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_athAPP•12/21/24, 3:38 PM

thnaks alot ! Good tip about POSIX too;

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

Similar Threads

Similar Threads

Similar Threads