coveralls
commented
1 year ago Pull Request Test Coverage Report for Build 4253223575
Warning: This coverage report may be inaccurate.
This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.
- For more information on this, see Tracking coverage changes with pull request builds.
- To avoid this issue with future PRs, see these Recommended CI Configurations.
- For a quick fix, rebase this PR at GitHub. Your next report should be accurate.
Details
- 142 of 147 (96.6%) changed or added relevant lines in 10 files are covered.
- 2 unchanged lines in 2 files lost coverage.
- Overall coverage increased (+2.3%) to 91.078%
| Changes Missing Coverage | Covered Lines | Changed/Added Lines | % | ||
|---|---|---|---|---|---|
| src/pytest_mock_resources/container/base.py | 22 | 23 | 95.65% | ||
| src/pytest_mock_resources/sqlalchemy.py | 17 | 18 | 94.44% | ||
| src/pytest_mock_resources/patch/redshift/psycopg2.py | 3 | 6 | 50.0% | ||
| <!-- | Total: | 142 | 147 | 96.6% | --> |
| Files with Coverage Reduction | New Missed Lines | % | ||
|---|---|---|---|---|
| /tmp/pytest-of-runner/pytest-1/test_multiprocess_container_cleanup_race_condition0/conftest.py | 1 | 85.71% | ||
| /tmp/pytest-of-runner/pytest-1/test_multiprocess_redis_database0/conftest.py | 1 | 85.71% | ||
| <!-- | Total: | 2 | --> |
| Totals | |
|---|---|
| Change from base Build 3959857831: | 2.3% |
| Covered Lines: | 1319 |
| Relevant Lines: | 1439 |
…sfixture(async=True).
Refactors a lot of the internal implementation of postgres/redshift fixture instantiation to avoid the (prior) requirement to instantiate synchronous engines in the fixture setup leading up to the yield point where we ultimately produce an async engine.
Meant to address https://github.com/schireson/pytest-mock-resources/issues/182, which requests that the async version of the postgres fixture function without psycopg2 installed.
TODO:
Be aware that this necessarily changes the container-level connection process. Now the
check_fnwhich checks to ensure that there exsits a container is currently just attempting a socket connection rather than fully connecting to the database.This is because the connection process necessarily requires a driver choice, which executes in a context which we cannot know is going to be sync or async, based on the (curent) design of how the parent "container" level fixtures function.
Perhaps we could add a specialized version if the
pg_isreadyutility is available. We could then shell out to that in order to check readyness more reliably. I personally have this utility handy on my machine, but it might not be available in every context.The consequence of this is that the "container" level fixture will bind, even if the user/password is incorrect...or really anything that is bound to the port you're trying to target. It will only retry-loop attempt to connect at the engine/session-level fixture. So most users should see the same behavior either way, except if using the container fixture exclusively.