-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
tests/unittests: add unit tests for core_mbox #18950
Conversation
hm, CI didn't build anything here. |
Ooopsie :/ |
return i + 1337; | ||
} | ||
|
||
static void test_mbox_put_get(void) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not be more verbose? For example, test_mbox_reject_message_if_queue_is_full()
[or adding comments to the current code] gives a good hint on what kind of behaviour to expect from mbox.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note that splitting it into smaller functions would have multiple downsides:
- code size (which is indeed an issue for the unit tests)
- setting up the mbox in the situation to test (e.g. try_put failing on a full mbox) assumes that mox_try_put does actually work at least to some degree correctly. We may end up either having the setup also being carefully checked, or misleading users to assume that e.g. try_put succeeds on a full mbox, while maybe the mbox just wasn't full due to another issue.
- more overhead to read (right now the function is neither too long nor too complex to grasp in its entirety with a quick look, so there is not yet anything to gain from splitting it)
I could add some comments, though
ed81cea
to
9b3df5b
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
bors merge
18632: tests/thread_float: do not overload slow MCUs with IRQs r=benpicco a=maribu ### Contribution description If the regular context switches are triggered too fast, slow MCUs will be able to spent little time on actually progressing in the test. This will scale the IRQ rate with the CPU clock as a crude way too keep load within limits. ### Testing procedure The unit test should now pass on the Microduino CoreRF ``` $ make BOARD=microduino-corerf AVRDUDE_PROGRAMMER=dragon_jtag -C tests/thread_float flash test make: Entering directory '/home/maribu/Repos/software/RIOT/tests/thread_float' Building application "tests_thread_float" for "microduino-corerf" with MCU "atmega128rfa1". [...] text data bss dec hex filename 12834 520 3003 16357 3fe5 /home/maribu/Repos/software/RIOT/tests/thread_float/bin/microduino-corerf/tests_thread_float.elf avrdude -c dragon_jtag -p m128rfa1 -U flash:w:/home/maribu/Repos/software/RIOT/tests/thread_float/bin/microduino-corerf/tests_thread_float.hex [...] Welcome to pyterm! Type '/exit' to exit. READY s START main(): This is RIOT! (Version: 2022.10-devel-858-g18566-tests/thread_float) THREADS CREATED Context switch every 3125 µs { "threads": [{ "name": "idle", "stack_size": 192, "stack_used": 88 }]} { "threads": [{ "name": "main", "stack_size": 640, "stack_used": 220 }]} THREAD t1 start THREAD t2 start THREAD t3 start t1: 141.443770 t3: 141.466810 t1: 141.443770 t3: 141.466810 t1: 141.443770 t3: 141.466810 t1: 141.443770 t3: 141.466810 t1: 141.443770 t3: 141.466810 t1: 141.443770 t3: 141.466810 t1: 141.443770 make: Leaving directory '/home/maribu/Repos/software/RIOT/tests/thread_float' ``` (~~Note: The idle thread exiting is something that should never occur. I guess the culprit may be `cpu_switch_context_exit()` messing things up when the main thread exits. But that is not directly related to what this PR aims to fix. Adding a `thread_sleep()` at the end of `main()` does indeed prevent the idle thread from exiting.~~ Update: That's expected. The idle thread stats are printed on exit of the main thread, the idle thread does not actually exit.) ### Issues/PRs references Fixes #16908 maybe? 18950: tests/unittests: add unit tests for core_mbox r=benpicco a=maribu ### Contribution description As the title says ### Testing procedure The test cases are run on `native` by Murdock anyway. ### Issues/PRs references Split out of #18949 19030: tests/periph_timer_short_relative_set: improve test r=benpicco a=maribu ### Contribution description Reduce the number lines to output by only testing for intervals 0..15 to speed up the test. In addition, run each test case 128 repetitions (it is still faster than before) to give some confidence the short relative set actually succeeded. ### Testing procedure The test application should consistently fail or succeed, rather than occasionally passing. ### Issues/PRs references None 19085: makefiles/tests/tests.inc.mk: fix test/available target r=benpicco a=maribu ### Contribution description `dist/tools/compile_and_test_for_board/compile_and_test_for_board.py` relies on `make test/available` to check if a test if available. However, this so far did not take `TEST_ON_CI_BLACKLIST` and `TEST_ON_CI_WHITELIST` into account, resulting in tests being executed for boards which they are not available. This should fix the issue. ### Testing procedure #### Expected to fail ``` $ make BOARD=nrf52840dk -C tests/gcoap_fileserver test/available $ make BOARD=microbit -C tests/log_color test/available ``` (On `master`, they succeed, but fail in this PR.) #### Expected to succeed ``` $ make BOARD=native -C tests/gcoap_fileserver test/available $ make BOARD=nrf52840dk -C tests/pkg_edhoc_c test/available $ make BOARD=nrf52840dk -C tests/log_color test/available ``` (Succeed in both `master` and this PR.) ### Issues/PRs references None Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
Build failed (retrying...): |
Build succeeded: |
Thx :) |
Contribution description
As the title says
Testing procedure
The test cases are run on
native
by Murdock anyway.Issues/PRs references
Split out of #18949