-
Notifications
You must be signed in to change notification settings - Fork 115
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
Provide better error output for test_satellite_installation #17105
Conversation
Quoting PEP 20: > Flat is better than nested.
This should help pytest to provide a better output.
If the installer failed, there's no point to continue. Since Foreman 3.8 it provides exactly which steps failed which is preferred over "parsing" the log file. Having an assertion in a fixture should result in the the test showing up as ERROR. Link: https://medium.com/opsops/pytest-fail-in-a-fixture-and-in-a-test-2122fab0564 Link: theforeman/foreman-installer@0d2fb67
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 had some issues with the installer_satellite
fixture. I don't like that it always asserts success. Ideally speaking we would also test for failures. When I looked I could only find a single test that used this fixture, so perhaps it should be refactored to just present an empty machine and have the installer command be part of the test itself.
@@ -395,6 +394,9 @@ def installer_satellite(request): | |||
).get_command(), | |||
timeout='30m', | |||
) | |||
# exit code 0 means no changes, 2 means changes were applied succesfully | |||
assert installer_result.status in (0, 2), installer_result.stdout |
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 also debated assert 'There were errors detected during install
not in installer_result.stdout` or similar.
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.
Given we have the failed_when
check based on satellite-installer RC, I wouldn't diverge from that in robottelo.
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.
Nice and clean, thank you!
When I looked I could only find a single test that used this fixture, so perhaps it should be refactored to just present an empty machine and have the installer command be part of the test itself.
From my point of view, this seems like a good idea. Would you be open to making the change sometime in the future?
@@ -395,6 +394,9 @@ def installer_satellite(request): | |||
).get_command(), | |||
timeout='30m', | |||
) | |||
# exit code 0 means no changes, 2 means changes were applied succesfully | |||
assert installer_result.status in (0, 2), installer_result.stdout |
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.
Given we have the failed_when
check based on satellite-installer RC, I wouldn't diverge from that in robottelo.
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.
Looks good. I have just added some labels to cherrypick this into older branches.
The installer_satellite fixture was meant to be used within ipv6 installation test. But we decided to use different approach to test ipv4 and ipv6 installations. And the ipv6 stubbed testcases were removed recently - #16963
I'm open to it, but I can't promise anything.
Does that mean we can remove a lot of the fixture? Or really, I see there's also My confusion is mostly from various tests like |
trigger: test-robottelo |
PRT Result
|
IMO test code has been heavily changed and has become more complicated because of |
(cherry picked from commit c170b84)
(cherry picked from commit c170b84)
That makes sense to me. When I was thinking about it, I think the fixture does too many things but untangling requires much more thought. |
Problem Statement
The current output of
test_satellite_installation
is useless. Because the output is so long, pytest truncates it which hides the relevant error.Solution
As a first step, it does a trivial cleanup for readability. The next commit stops using
len(x) == 0
and instead usesnot x
to assert there is no output. I haven't tested this, but I believe this allows pytest to skip a layer of output and hopefully also provide better output.The real change is that it asserts the exit code of the installer to be 0 or 2. In practice I'd always expect 2, but 0 is also valid. See https://github.com/theforeman/kafo?tab=readme-ov-file#exit-code for more information. Since foreman-installer 3.8.0 (theforeman/foreman-installer@0d2fb67) it also displays structured output on the exact failure.
Related Issues
trigger: test-robottelo
pytest: tests/foreman/ui/test_contenthost.py -k 'test_satellite_installation'