test(fixtures): cache the base example project directory #799
+285
−130
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.
Purpose
Improve speed of test code and reduce the number of IO operations
Rationale
In other development towards changelog testing, I came across the high use of IO operations as we rebuild a project with each test case. This causes a lot of IO operations, and even more so on the use of git. I followed the rabbit hole, and this PR is the first of a few that help increase the test execution speed through deliberate abstraction/modularity. I felt it all at once would be way to confusing and too much for a good review.
How I tested
Besides checking the result here in the CI, I originally was able to confirm the caching mechanism through the VSCode debugger and many break points through the code to see how many times each fixture was called. Once this commit was implemented, the session scope ensured that it was only called once but the init fixture called every test run.
How to Verify
To get VSCode to run the debugger, you have to change the
tool.pytest.ini_options.addopts
by removing the--cov*
options and then changing-nauto
to-n0
. Once you do this, add a breakpoint to the start ofinit_example_project
, andcached_example_project
. Then execute a test (a minimum of 2 that useinit_example_project
) with the debugger. When you step through, you will see how many times each is called, and you will see the cleanup occur as well if you put a few breakpoints inteardown_cached_dir
.