This feature is currently only available on Momentic Cloud. When using the Momentic CLI, you can leverage your CI provider to implement setup and teardown. For example, a step marked with if: always() in a GitHub actions workflow file will always run at the end.

Usage

When editing a suite on Momentic Cloud, you have the option of choosing a “setup test” and a “teardown test”.

The setup test will always run first before any other tests in the suite. If it fails, the rest of the suite will be skipped and the entire suite will be marked as failed.

If the setup test succeeds, Momentic will continue running the main tests in the suite. Just as normal, if any of the tests fail, the entire suite will be marked as failed.

Whenever the suite’s final result is determined (one of pass, fail, or cancelled), Momentic will start running the teardown test. The teardown test’s result does not affect the overall suite result.

Passing data between sections

To allow passing data between each section of a suite, Momentic exposes the setPersistentVariable function in JavaScript execution contexts. This function allows users to set a variable that will be passed to the env of every test in the rest of the suite.

The most common use case is passing the identifier of a fixture (e.g. account ID) created in the setup section for usage and cleanup in the later sections.

Why use setup or teardown?

Fixtures are fixed resources that are useful for a single testing session. For example, if you are testing a login flow, you may need to create a user account, log in, and then verify that the user is logged in. The user account, in this example, is a fixture.

While Momentic’s recommendation is to use isolated environments for each testing session, this may not always be feasible. Long-lived staging or UAT environments are commonly employed when certain infrastructure components such as third-party services cannot be efficiently spun up for each testing session.

In these cases, it is desirable to have a single fixture setup section that runs before all other tests, and a single fixture teardown section that always runs after all other tests.

This architecture guarantees two properties:

  1. The fixtures are always setup correctly before the main tests run. This eliminates the need for complex coordination or sharing logic between the main tests.
  2. The fixtures are always torn down after the main tests are run. This prevents a continuous build-up of fixtures in the testing environment and also ensures the environment is in the correct state for future testing sessions.

Was this page helpful?