-
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
sys/test_utils/result_output: Initial implementations and API of turo #15950
Conversation
0290023
to
84f95c3
Compare
TODO:
|
All that is done, I probably should split this PR up. @leandrolanzieri thanks for the kconfig help |
Do you really expect that people who write test applications will use |
I have been asking about this for a while... For simple things maybe not (hence optional) but if I am writing a more complex test that I uses a matching python module for might be useful. Does it make sense to try to enforce a structure when writing tests? For the tests or modules that use, say json strings, would it not be better to use some common functions instead of always |
I agree that in certain situations such a module could be useful: for benchmark tests or very complex tests, as you say. For tests that are just there as usage examples, it's important to keep them as self-explanatory as possible and to limit the usage of test specific modules, eventually they could be moved to the examples directory instead (but in this case, we need a hierarchy of directories instead of the actual flat organization 🤔 ). |
I think that has also been discussed quite a bit :) @aabadie Is that a blocker for you or can we proceed with the concept (again, optional only if it makes sense for that test)? |
eb43f7f
to
887e4e2
Compare
tests/turo/main.c
Outdated
* Copyright (C) 2014 Freie Universität Berlin | ||
* | ||
* This file is subject to the terms and conditions of the GNU Lesser | ||
* General Public License v2.1. See the file LICENSE in the top level | ||
* directory for more details. | ||
*/ | ||
|
||
/** | ||
* @ingroup tests | ||
* @{ | ||
* | ||
* @file | ||
* @brief GET_CPU_ID() test application | ||
* | ||
* @author Martine Lenders <[email protected]> | ||
* @author Hauke Petersen <[email protected]> |
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.
This does not seem to be correct ;-)
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.
Could be... could be
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.
fixed
Now the LED module is dripped this is a bit simpler PR. Any remaining objections? |
#15950 (comment) remains uncommented. |
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.
If this one was addressed, I think we can merge.
* | ||
* Some of the design decisions include: | ||
* - ability to flush immediately to prevent the need for large buffers | ||
* - selectable output format based on USEMODULE |
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.
I think this was not addressed yet too.
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.
This is ready to go in my opinion. I think your changes were addressed too, @kaspar030, right?
Pleases squash, @MrKevinWeiss. |
4696894
to
01f7173
Compare
01f7173
to
b1be11c
Compare
@kaspar030 gave a thumbs up to my ACK, which I interpret that we can dismiss his review. Please re-request changes, if that is not the case.
Sadly, Murdock's not happy :( |
Took me a while to interpret the output: apparently there are now different binaries generated with and without Kconfig. |
Hmmm, I will look into it. |
b1be11c
to
2e5ff00
Compare
It seems I struggled with the rebasing and removing of the module. I make the turo module optional in kconfig and default select json. |
@miri64 I think things are looking good now! |
🎉 then let's go! |
Thanks for the review! |
Contribution description
The latest in an effort to add an abstraction layer for RIOT tests allowing a more stable testing API.
This focuses more on how results are printed or output.
Using the results_output API will allow a guaranteed way output data, meaning no more needing to adapt regex everytime a printf is changed.
The exact output can be changed depending on the module selected, this means if you don't like it you can just implement a variant that suits your needs.
The eventual goal will be to coordinate this with
riotctrl
so data can be used immediately when writing python based automated tests.There are currently 4 variant implemented:
turo_t *ctx
to flash LEDsMore information is in the
sys/test_utils/results_output.h
file.Note: The
test_utils_result_output_json
isnotfully json compliantas it contains trailing commas. This is allows simple flushing of information and no need for states. Many parses accept trailing commas such as.rapidjson
python parserTesting procedure
OUTPUT_FORMAT={txt, check, json, led} make all -C tests/turo
note: native has "leds" but they don't fit the LED0_PIN define so an assertion error will be thrown because native uses GPIO_UNDEF
Issues/PRs references
supersedes #15039
also supersedes #11224
Implementation of a cleaner idea of #10624