-
Notifications
You must be signed in to change notification settings - Fork 2k
[TST]: speed up test_embeddings.py against cluster #4796
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
Conversation
Reviewer ChecklistPlease leverage this checklist to ensure your code review is thorough before approving Testing, Bugs, Errors, Logs, Documentation
System Compatibility
Quality
|
itaismith
left a comment
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!
|
Parallelize and Accelerate test_embeddings.py for Cluster Execution This PR optimizes and parallelizes the property-based test suite test_embeddings.py when run against a cluster, reducing runtime significantly (~25m to ~16m). Key improvements include more frequent polling for collection version changes, centralization of isolated database creation, and updates to related utils and workflow configuration to further accelerate other tests (e.g., test_filtering.py). The isolated database setup logic is now shared and reused across test modules, reducing overhead and inter-test dependencies. Key Changes: Affected Areas: This summary was automatically generated by @propel-code-bot |
## Description of changes Speeds up `test_embeddings.py` against the cluster: `~25m -> ~16m`. The test is now parallelized and checks for new collection versions at a higher frequency (the collection version change has the side effect of also speeding up `test_filtering.py`). ## Test plan _How are these changes tested?_ - [x] Tests pass locally with `pytest` for python, `yarn test` for js, `cargo test` for rust
Description of changes
Speeds up
test_embeddings.pyagainst the cluster:~25m -> ~16m. The test is now parallelized and checks for new collection versions at a higher frequency (the collection version change has the side effect of also speeding uptest_filtering.py).Test plan
How are these changes tested?
pytestfor python,yarn testfor js,cargo testfor rust