Split server tests out by database #14992
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
QA Wolf here! As you write new code it's important that your test coverage is keeping up. |
…to split-server-tests-out-by-database
…ase/budibase into split-server-tests-out-by-database
samwho
requested review from
adrinr and
mike12345567
and removed request for
a team and
adrinr
mike12345567
approved these changes
Nov 18, 2024
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
Description
Prior to this PR, our
test-serverpart of the CI process ran the full test suite forpackages/serverin a single runner, with all of the databases we test against running at the same time. This necessitated us running on larger runners than the default due to the memory usage, and over time has grown to take over 15 minutes.This PR splits
test-serverout into per-database shards. Each shard runs the specific database being tested against, and only runs tests that depend on that database. There's an extra shard for tests that do not require a database to be running.This is all achieved through a new test function called
datasourceDescribe. This is designed to act like a normal Jestdescribe, except you pass in the datasource types you want to test against and it manages the setup of the datasources for you. It also takes into account aDATASOURCEenvironment variable, which you can specify to limit the tests to just that datasource. This is how we limit CI to specific datasources.I'm also making use of Jest filters to be able to split tests into ones that need a datasource (by looking for the string
datasourceDescribein each test file), and ones that don't.