Skip to main content

Behind the scenes...

The depot-test framework is made of two components:

  • a TypeScript library providing the DepotTest primitive, jest matchers, etc.
  • a back-end process written in Java, executes the scenarios

The typical interaction looks like the following:

Your test code runs under jest, which sequences execution.

When each of your individual tests runs, it prepares a test scenario using DepotTest or the legacy schemaTest or objectTest interfaces.

The depot-test TypeScript library packages the test scenario and delegates it to the underlying Java back-end, which runs on the same machine. The back-end, in turn, converts the scenario into a sequence of SQL statements and interprets the results.

In more detail​

The following interaction takes place:

Profiles​

The list of profiles and the active profiles are retrieved from the backend by the frontend using simple REST calls:

  • GET http://localhost:${port}/profiles returns the list of profiles
  • GET http://localhost:${port}/profiles/active returns the id of the current active profile

The frontend blends the profile flags with the current environment variables to produce the effective test job parameters.

note

Unsupported but just in case:

It is possible to programmatically switch the active profile by sending a PUT request to http://localhost:${port}/profiles/active?profile=${profileId}. This is not a supported feature unless it proves useful in e.g. a CI scenario (please consult with the Island team if you're planning to make use of this).

When parallel tests run​

When you run multiple tests in parallel, only one backend will keep running; tests will locate the backend and delegate their scenarios to it. The backend will run the scenarios as much in parallel as possible, within the limits of the Snowflake account.

When jest runs multiple tests in parallel, it will leverage Node's workers mechanism to run each test module in parallel (by default, it runs a worker per available processor core, or less if --maxWorkers=X is set). Each worker runs a test module in complete isolation from its neighbours.

Test modules that use the current DepotTest interface, which is asynchronous, will directly attempt to locate the back-end and then delegate their scenarios to it.

Test modules that use the legacy schemaTest or objectTest interface, which are synchronous, will run an intermediate "bridge" process that will perform the delegation to the back-end.

Starting the back-end process​

There is normally exactly one back-end process running on your machine or the CI runner. It is started when needed by the TypeScript side of depot-test.

When a heavily parallel test suite starts, many instances of depot-test might simultaneously attempt to start the back-end at the exact same time. To avoid this, the following state machine is observed: