chore: require an empty target database for integration tests#423
Conversation
The integration tests create and drop collections, tables and keyspaces on
the target database. Running them against a database that is already in use
risks clobbering its data.
Add an autouse, session-scoped guard fixture in tests/base/integration that
lists the collections and tables in the working keyspace before any test data
is provisioned. When the keyspace is not empty:
- in CI (CI env var set) the run is failed hard (pytest.exit, non-zero
exit code), so a non-empty database cannot produce a green-but-skipped
check that lets an untested PR merge;
- locally the suite is skipped, to protect the developer's data.
Either way the destructive test fixtures never run against a populated DB.
127e795 to
3e49c02
Compare
|
Thanks for taking a stab at this feature!
So I would expand the check by ensuring there are no collections/UDTs/tables across all keyspaces that are not 'system keyspaces'. Let me see how that could work (rought draft, I tested it in the basic cases): WDYT? Keep in mind this can be de-prioritized if we are tight on the 2.3-release things! :) |
|
Thank you @sl-at-ibm :) I agree with you. I updated the fixture so the behavior is now consistent locally and in CI: it exits early with an error if the target database is populated, unless i also applied it across keyspaces... it filters system keyspaces, and checks collections/tables/UDTs across all non-system keyspaces. I used I left this scoped to the base integration suite for now since that is the always-run/CI-covered suite, but I agree the same guard could be extracted/shared for vectorize tests. In fact, heck, let's add that really quick. I was going to say it could go in a follow up, but it probably makes sense just to have it here!... Done. By the way, the i hardcoded the list of system keyspaces... do you know of a simple data-api way to get that list dynamically? i can update it if so... |
|
Awesome, Eric, thank you!
I am not aware of such a handy cool thing and I highly doubt there is one. For now, at least, we can safely keep the hardcoded list without worrying too much (it's not even user-facing stuff anyway ...) |
Coverage reportfor commit: |
sl-at-ibm
left a comment
There was a problem hiding this comment.
LGTM, thanks for doing that! (you may want to check the suggestion I left)
Data API already does this filtering
Coverage reportfor commit: |
Summary
Adds a fail-fast guard for integration tests when the target database is already populated.
The guard now:
TOLERATE_POPULATED_DATABASE=yesfor intentional narrow local test runsThis is meant to catch leftover test objects early, before a long run fails later with object-limit/conflict errors.
Test plan
make formatTOLERATE_POPULATED_DATABASE=yesbypasses the guard for intentional narrow local runs