ci: initial implementation of top-level pytest tests #433
Conversation
|
Hi @jiridanek. Thanks for your PR. I'm waiting for a opendatahub-io member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
|
Yeah, this, @jstourac just mentioned this PR at a meeting, asking about status |
|
@jiridanek: The following tests failed, say
Full PR test history. Your PR dashboard. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
jiridanek
force-pushed
the
jd_2024_02_24_unittests
branch
from
5fbdfdb
to
47a69e8
Compare
jiridanek
force-pushed
the
jd_2024_02_24_unittests
branch
3 times, most recently
from
87fc54c
to
20b7c4f
Compare
jiridanek
added
ok-to-test
tide/merge-method-squash
and removed
do-not-merge/work-in-progress
needs-ok-to-test
labels
jiridanek
changed the title
There was a problem hiding this comment.
I wonder - do we plan to utilize this also for the functional testing of the build images or is this planned just as a set of checks for something like the static code analysis? Maybe a combination of both?
My concern here is that we don't introduce yet another "static code" check which we already have written in bash scripts elsewhere. The ultimate goal should be to replace the current Makefile like testing approach with something more flexible, cleaner and more scalable. Does this apply to this approach?
| id: setup-python | ||
| uses: actions/setup-python@v5 | ||
| with: | ||
| python-version: '3.12' |
There was a problem hiding this comment.
I'm wondering whether such new python version won't collide with possible future basic functional tests to test actual python packages? Shouldn't we rather stick to what we have in 2024a branch, that means Python 3.11? 🤔
There was a problem hiding this comment.
Python 3.12 is not a problem. I think that that would be a valid comment for what @paulovmr is doing in
(and he has that handled, in his PR there's a separate env for every image)
Here, if we wanted to run something inside the images, which is the only meaningful way to do functional tests of packages installed in images, then we would naturally not use the python, package version, or lock file maintained in the top level by poetry, but we'd run pip install the same way as the current makefile tests install papermill, etc.
There was a problem hiding this comment.
I wonder - do we plan to utilize this also for the functional testing of the build images or is this planned just as a set of checks for something like the static code analysis? Maybe a combination of both?
I want to use https://github.com/testcontainers/testcontainers-python to test the built images.
My concern here is that we don't introduce yet another "static code" check which we already have written in bash scripts elsewhere. The ultimate goal should be to replace the current Makefile like testing approach with something more flexible, cleaner and more scalable. Does this apply to this approach?
Absolutely; replacing static checks with Python would be also nice, I think, but the main goal for me is testing the built images.
| id: setup-python | ||
| uses: actions/setup-python@v5 | ||
| with: | ||
| python-version: '3.12' |
There was a problem hiding this comment.
Python 3.12 is not a problem. I think that that would be a valid comment for what @paulovmr is doing in
(and he has that handled, in his PR there's a separate env for every image)
Here, if we wanted to run something inside the images, which is the only meaningful way to do functional tests of packages installed in images, then we would naturally not use the python, package version, or lock file maintained in the top level by poetry, but we'd run pip install the same way as the current makefile tests install papermill, etc.
``` $ poetry init $ poetry add --dev pytest $ poetry add --dev pytest-subtests ```
jiridanek
force-pushed
the
jd_2024_02_24_unittests
branch
from
20b7c4f
to
2c5a8da
Compare
|
New changes are detected. LGTM label has been removed. |
|
[APPROVALNOTIFIER] This PR is APPROVED Approval requirements bypassed by manually added approval. This pull-request has been approved by: jstourac The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
[RHOAIENG-15710] fix the version of codeflare-sdk shown for 2024.1
Description
This establishes a top level Poetry-managed environment for writing tests for Notebooks in Python. There is currently a single test to check that all
Pipfiles have the correct python version specified in them.Documentation
Pytest supports two styles of writing tests, either class-based (
unittestpackage style) or function and fixtures-based (pytestpackage style). Here's docs for the unittests approach https://docs.python.org/3/library/unittest.html#basic-example, and for the support in Pytest https://docs.pytest.org/en/7.1.x/how-to/unittest.html.Main advantage of Pytest is that it can export results as JUnit XML files out of the box, and that it supports assertions using the
assertkeyword, instead of having to use the assert methods.How Has This Been Tested?
Merge criteria: