Make Tests Take Optional Dependencies Into Account#148
Make Tests Take Optional Dependencies Into Account#148Urist-McGit merged 9 commits intosiemens:mainfrom
Conversation
Conditionally skip tests using `pytest.importorskip` and move all required dependencies for a given test into the test function's body. Signed-off-by: Max R. Carrara <max@aequito.sh>
While `from_str` works fine if called explicitly on the `SBOMType` enum, calling it on one of its variants throws a `TypeError`. Make it a proper classmethod to prevent this. Signed-off-by: Max R. Carrara <max@aequito.sh>
Implement `__str__` for `SBOMType` in such a way that the following
expression is idempotent:
bomtype = SBOMType.from_str(str(bomtype))
Also add a default case that's unreachable [0] so that one's type
checker catches unhandled cases, should more enum variants ever be
added in the future.
[0]: https://typing.python.org/en/latest/guides/unreachable.html#marking-code-as-unreachable
Signed-off-by: Max R. Carrara <max@aequito.sh>
|
Thanks for all the packaging work! We will certainly come back to you about the packaging in Debian since we want to do that at some point in the future aswell.
|
|
We might want to test this feature in CI, we already have test setups to see if |
Create a list of SBOM types directly from the `SBOMType` enum's `__iter__` dunder method in order to make the graphml export test automatically parametrized for all (future) SBOM types. Signed-off-by: Max R. Carrara <max@aequito.sh>
Leverage the fact that the graphml export test is parametrized using enum variants instead of strings in order to conditionally skip running the test for a given type if its associated dependency cannot be imported. While the default unreachable [0] case isn't necessarily caught by type checkers, it still trips up when the graphml export test runs for an unhandled SBOM type. [0]: https://typing.python.org/en/latest/guides/unreachable.html#marking-code-as-unreachable Signed-off-by: Max R. Carrara <max@aequito.sh>
For the `sbom_generator` fixture, acquire the list of SBOM types directly from the enum's `__iter__` dunder method to make maintenance of tests a little bit easier, should a new SBOM type ever be added in the future. Signed-off-by: Max R. Carrara <max@aequito.sh>
Conditionally skip tests using `pytest.importorskip`. Note that which dependencies are required for a given test was determined by hand, that is by installing none, only one, and both of the dependencies and then running the tests. Signed-off-by: Max R. Carrara <max@aequito.sh>
Conditionally skip tests using `pytest.importorskip` and move all required dependencies for a given test into the test function's body. Signed-off-by: Max R. Carrara <max@aequito.sh>
... in order to silence linters. Signed-off-by: Max R. Carrara <max@aequito.sh>
3a920af to
f1a7242
Compare
@Urist-McGit Woops, sorry about that! That one slipped through. Fixed it now. |
fmoessbauer
left a comment
There was a problem hiding this comment.
Many thanks for this PR. We will take care of adding the conditional CI tests.
PS: I was just in contact with the maintainer of python-spdx-tools which is now in Debian unstable as well. I'll write a ITP for the debsbom package.
Basically what the title says.
In order to get
debsbomto build on Debian trixie using the bespoke Debian tooling & helpers, thepytestunit tests must also take the optional dependencies into account.This PR makes it so that the affected tests only run when either one of the SBOM format dependencies (in particular
spdx-toolsandcyclonedx-python-lib) are installed.In other words, the tests will be skipped / run accordingly, if:
spdx-toolsis installedcyclonedx-python-libis installedAlso, refactor some things here and there where this PR touches things along the way (or in preparation) to make things a little neater for everyone involved.
The commit messages contain additional details for each set of changes.
No breaking changes are made.
Side note: You guys have been really busy since I last checked in—thank you so much for incorporating my feedback that quickly! I've just bumped / adapted our internal packaged version for trixie and everything's packaging smoothly now, no backports necessary (unless we actually need support SPDX, but that's yet to be determined).
I'll see if I can either upstream our internal packaging to Debian directly at some point, or at least provide the things we've been doing to you, so you can use it for your own purposes as well. Can't give an ETA on when that will happen yet, though.