Tests: refactor to drop pytest and start using the kernel module#214
Open
brenns10 wants to merge 8 commits into
Open
Tests: refactor to drop pytest and start using the kernel module#214brenns10 wants to merge 8 commits into
brenns10 wants to merge 8 commits into
Conversation
Pytest allows writing tests slightly more ergonomically. The fixtures are especially nice, as is parametrization. But ultimately, it isn't really worth the added dependencies it brings in. Due to API changes over time we cannot install the RPM directly, and due to Python 3.6 compatibility we've had to stick with pytest <7. Previously, due to the large amount of test files, migrating out hasn't been feasible without a major time investment. Thankfully, Codex was willing to make that investment in tokens instead of my time. Signed-off-by: Stephen Brennan <stephen.s.brennan@oracle.com>
Some workqueue tests have wrongly passed because they assert "list.sort() == list.sort()". However list.sort() modifies a list in place and returns None. So the assertion trivially passes but does not actually verify anything. On UEK8, the assertions have actually been broken, masking some changes that have to do with the naming of rescue kthreads, as well as the addition of BH workqueues in 6.9. Signed-off-by: Stephen Brennan <stephen.s.brennan@oracle.com>
With pytest, a bare "assert" statement is used, and the test runner is smart enough to parse the expression and output a useful comparison on a test failure. With unittest, "assert" works but only shows that the condition failed. Helpers like "self.assertGreater" are provided to give a richer error message when an assertion failure occurs. Migrate all bare assertions to unittest style assertions. The result is slightly more verbose code, but it will be easier to debug test failures. Compared to the previous migration, this one is small, because we have relatively few tests that actually... assert things. This is something I'll try to improve in some upcoming commits as well. Signed-off-by: Stephen Brennan <stephen.s.brennan@oracle.com>
There's no need for a separate "show_cmdline()" function. Also, /proc/cmdline can be used to trivially verify the result. Do so. Signed-off-by: Stephen Brennan <stephen.s.brennan@oracle.com>
The bulk of the real testing for "lock" has been the lockmod vmcores. But it is not really feasible to regularly add new vmcores. Now that we have the capability of the test kernel module, import the lockmod code which was used to generate them and add it to the kmod. We can reuse the bulk of the lockmod vmcore tests as-is. This revealed that a breakage had occurred for some kernels with CTF. Drgn 0.0.32 updated the StackFrame.name logic to fall back to the symbol name. This is generally good, but the lock code had implicitly relied on the prior behavior to detect that a stack frame's name came from DWARF, not a symbol, and thus it did not need to have any optimization attributes (constprop, isra, etc) stripped from its name. Now that symbol names may be present in StackFrame.name, we can drop the logic to check StackFrame.symbol(), and we need to strip symbol suffixes unconditionally. This fixes the tests on all current live kernels. As a nice bonus, we now can easily verify that the lock module works on RHCK too! Signed-off-by: Stephen Brennan <stephen.s.brennan@oracle.com>
The commit 63bab43 ("lock: add helpers to work with completion variables.") added the necessary helpers for including completions in the lock module. But it did not actually add it to the corelens module. It also did not add any testing for identifying completions -- understandably, since it's quite difficult. Now that we have testing for the lock module through the kernel moudle, we can add proper testing. This reveals that the support had two errors with UEK6. Fix these alongside adding the tests. Signed-off-by: Stephen Brennan <stephen.s.brennan@oracle.com>
Signed-off-by: Stephen Brennan <stephen.s.brennan@oracle.com>
oracle-contributor-agreement
Bot
added
the
OCA Verified
It's not uncommon for debuginfo to be out-of-sync with the released RPM. The DRGN_TOOLS_ALLOW_MISSING_LATEST setting defaults to 0, but let's default it to 1 instead. This allows us to transparently fall back to older RPMs if the full set of RPMs (including debuginfo) is not available for the latest. We'll still fail if the latest 5 are missing. Signed-off-by: Stephen Brennan <stephen.s.brennan@oracle.com>
biger410
approved these changes
Jun 5, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
I apologize in advance for the size of this PR!
There are two commits that are responsible: the first one, which drops our dependency on pytest in favor of standard Python unit tests, and the third commit, which migrates the tests to use unittest-style assertions rather than
assertkeyword. You can see the commit message for both commits for some of the reasoning there.Both of those commits were assisted by Codex (they're quite big). I reviewed them myself, and they are mostly mechanical changes. Feel free to review them as well, but I'm pretty confident in them myself.
The remaining commits are fixes for real issues in our tests, or improvements in our tests. Again, each commit message has more information.