-
Notifications
You must be signed in to change notification settings - Fork 21
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
testutils: Automated testing environment for release tests using pytest #155
testutils: Automated testing environment for release tests using pytest #155
Conversation
Spec06 is still a bit flaky due to the custom |
Fixed the issue with spec 6. One issue was just a wrong assertion not in line with the release-specs and the other was that the timeout for the |
def pytest_keyboard_interrupt(excinfo): | ||
# pylint: disable=C0301 | ||
""" | ||
Called on KeyInterrupt | ||
|
||
See: https://docs.pytest.org/en/stable/reference.html?highlight=hooks#_pytest.hookspec.pytest_keyboard_interrupt | ||
""" # noqa: E501 | ||
for child in RUNNING_CTRLS: | ||
child.stop_term() | ||
for exp in RUNNING_EXPERIMENTS: | ||
exp.stop() |
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.
Another thing that is flaky, even with this function, is cleanup. When the tests run uninterrupted, everything is cleaned up properly, but once one hits Ctrl+C
during the tests some nodes and experiments might still be left running. Maybe someone with more experience with pytest
can help here. @aabadie @fjmolinas?
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.
(it seems that both commands wait a bit after doing the actual stopping while pytest is too impatient and just kills the waiting).
Mh nope, the timeout is allegedly still too short :-/. This doesn't seem right to me. It is calculated here from the input parameters: Release-Specs/testutils/shell.py Lines 125 to 128 in 0ddb383
So there should be more than enough time to wait for the prompt. However, it does not seem to be and the framework just fires a timeout in Release-Specs/testutils/shell.py Lines 129 to 134 in 0ddb383
Maybe the nodes don't really wait a |
Yeah seems like this. Instead of waiting 1s with |
Yepp, that worked :-) |
f5d6a79
to
9c62c0b
Compare
Squashed the last few commits regarding GitHub Actions into one. They are now working https://github.com/miri64/Release-Specs/actions/runs/164755513. For now, only the self-testing of the test framework is done and I plan to keep it that way for pull requests and pushes. If this gets merged I plan to provide a separate workflow to run release tests periodically (maybe weekly?). |
First run gone horribly wrong: https://miri64.github.io/Release-Specs/test-reports/test-report-rc1-2020-07-11-12-44.html |
I used |
With the latest round of commits the success rate should be much higher (also include some clean-up of code I was annoyed with). I'm just running the script again and will come back with the results. |
c2ceb5e
to
1176ee1
Compare
See #156 (comment). There only seems to be an issue with |
From that comment: does anybody know how to get the |
|
311c4a0
to
aa40c38
Compare
I don't assume anyone looked at my weekend-shift work, so I just squashed it all together into one fixup commit per base commit :-) |
This PR is getting quite large. Shall I split it up in one for the framework and one for each spec (with a tracking PR including all release tests implemented so far to ease testing)? |
8f0441e
to
266f1d7
Compare
Squashed in anticipation of that. |
266f1d7
to
648a5d3
Compare
Ok, I now removed all spec test implementations. It's still big, but there is a lot of ground work done here that is needed by the other PRs. |
self tests pass and code-wise looks ok overall. I used #164 to run all tests and the base script seems to work. Will run again with the last commit and I would say we are ready to go |
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.
All good. ACK
please squash before merging :) |
(we should maybe add commit lint to this repository too) |
Yes, but since there are a lot of legacy scripts still lingering, until everything is integrated, I would prefer to do that after all spec tests are merged (see 5a95f20). |
Co-Authored-By: Jose Alamos <jose.alamos@haw-hamburg.de> Co-Authored-By: Martine S. Lenders <m.lenders@fu-berlin.de>
Co-Authored-By: Francisco Molina <femolina@uc.cl>
2d482e8
to
cb6a644
Compare
Squashed. |
Contribution description
Third time's a charm: after #79 and some major overhaul of that framework to use (then)
riotnode
(nowriotctrl
) andpytest
by @fjmolinas, I ported the latter to run with the newriotctrl
python package and the in-treeriotctrl_shell
module.I also cleaned up the by now very complicated history of that effort and squashed a lot of commits. Since the most of the porting work was done by @fjmolinas (I just moved some code around and enhanced his code) I made him the main author of the work in the commit history, but added all co-authors to the respective commits for the changes they made.
Testing procedure
Run
tox
and the tests will be run (there are none at the moment, see #160, #161, #162, #163, #158, and #159).Check-out #164 to run all tests.
There is also some more info in the README how to select specific groups of tests.
Self-tests are run by Github Actions and can be run locally with
tox -- --self-test
.Issues/PRs references
Alternative to #79.
Required for #160, #161, #162, #163, #158, and #159