test (PoC): Interlaced testing #1256
Draft
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.
Concept
This PR is an alternative to #952.
Instead of having test blindly rely on guaranteed isolation an explicit approach of guaranteeing no side effects is taken to allow all tests to run together in the same deployment. For most application tests this approach is straight forward to be achieved as the best practice is to leverage
cds.UUID
as primary key of all entities. Providing a proven solution to prevent side effects between multiple different tests. Forcds-dbs
the test scenarios have to include non best practice models. Additionally it requires to testCREATE
andDROP
of entities. Which directly clashes with the interlaced testing approach once a table is dropped this has side effects on other tests. Therefor theCREATE.test.js
file was skipped for this PR for demonstrative purposes.Limitation
Current limitation is that
SQLite3
while running inWAL
mode will instantly reject a transaction when creating lock conflicts. Which prevent two tests from modifying a single entity at all. As this creates flaky tests.