Skip to main content

Make your life easier with modules

When you create your tests do you notice that they contain steps you have to repeat over and over, like logging in, setting up test data, or navigating to a deep page? Instead of recording the same “log in as admin” steps in twenty different tests, you can record it once as a module and then reuse it wherever you need it. When the test runs, AIVA executes the module exactly as if those steps were written directly in the test.

Two kinds of modules​

AIVA has two types of modules:

  • Authentication modules — for all the different ways users log in to your app. An authentication module’s flow must start with a Navigate to URL action. This is the classic “log in once, reuse everywhere” module.
  • Generic modules — reusable blocks of steps you can run anywhere in a test, not just at the start (for example, setting up test data or navigating to a deep page). You create a generic module by extracting a range of steps from an existing test in edit mode — generic modules can’t be created from scratch on the new-module page. A generic module can be re-recorded only if its flow starts with a Navigate to URL step; without one it has no standalone entry point, so re-recording (and running it on its own) is unavailable.

Whichever kind you use, AIVA executes the module’s steps at test time exactly as if they were written directly in the test.

Modules keep your tests short, clean, and easy to maintain — change the module once (e.g., your login flow changes slightly) and every test that uses it automatically gets the update.

Add a module to a test​

A module of either type is referenced by a Run module step. In a test’s edit mode, use the insert (+) menu and choose Module to drop a Run module: <name> step wherever the flow can continue from that point. The step is shown inline among the test’s other steps, with a link to open the module itself. You can also replace a Run module step with a different module from the step’s detail panel — this works for both authentication and generic modules.

There are two convenience shortcuts that create the referencing step for you:

  • Creating a test with an authentication module seeds the Run module step for you.
  • In edit mode you can extract a range of steps into a new module; the extracted steps are replaced in place by a Run module step referencing it.

For now, a module can’t contain another module. See Known limitations.

Modules always run their latest version​

You never have to “upgrade” a test to a newer module version — a test always runs the latest version of the module at run time. When you edit and confirm a new version of a module, every test that uses it picks up the change automatically on its next run.

On a finished test run, the module step shows which version actually ran:

  • latest — the run used the module’s current latest version.
  • outdated — the run used an older version than the current latest (older runs keep showing the version they really executed).
  • version unavailable — the exact version that ran no longer exists, because the module was later reverted to an earlier version. The step can’t open that version anymore; selecting the module offers to take you to its latest version instead.

Record authentication only once and reuse it​

If your tested app requires authentication of the user, your tests will generally all start with a login procedure, with only few exceptions.

If that’s the case, we suggest recording the login procedure as a module and using that module in all tests where it makes sense. This has several advantages:

  • You won’t have to re-record the login procedure over and over again, saving time and avoiding mistakes.
  • Your tests will be shorter and more readable.
  • Should anything change about the login procedure of your app, you will only have to reflect that change in one place, not all the tests.
  • In case of test failures, you will easily see whether it was the actual test that failed, or just the login procedure (perhaps indicating simply a wrong password, or the whole application being down).

As with tests, we suggest ending the module with an assertion, so you instantly know if the login itself failed instead of the test that comes after it.