Skip to main content

Design reliable tests with AIVA

We strive to make AIVA intuitively understandable and easy to use. If we did our job right, it should “just work.” Still, here are a few hints to get you started faster, and small habits that will help you get the most out of your test automation in AIVA.

Prefer clicking on text or icons instead of blank areas​

When you need to interact with an input field, dropdown, or checkbox, try to click on the field’s label text, an icon, or visible placeholder text instead of empty white space inside the box.

For example, let’s say your test needs to type something in this input field:

Text input field example with label and placeholder

You could click anywhere in the box and it will work. However, it is preferable to click the field label (if supported by the tested app) or the placeholder text.

Why? It will then be easier for AIVA to figure out a name for the element, or to find the element faster during test playback.

Recording steps in tables?

AIVA can recognize table cells and use table-specific search modes to find the correct row during replay. See Reliable table interactions for recommendations on recording steps in tables.

Keep tests focused and reasonably short​

A good rule of thumb: one test = one clear user goal.

Examples of well-scoped tests:

  • “Visitor can sign up with valid data”
  • “Logged-in user can add a product to cart and reach checkout”
  • “Admin can ban a user from the dashboard”

Very long “kitchen-sink” tests that try to do everything in one go (sign-up → login → browse → buy → logout) are harder to maintain and may fail for unrelated, non-obvious reasons. If you can break a test into two, do it. If you do need many steps in one test, it may be a good idea to break it into logical parts using modules.

Keep tests independent of each other​

Try to make each test able to start from a clean slate and run successfully on its own, without needing another specific test to have run first.

Why it helps: independent tests are predictable and safe. You can run them in any order, in parallel, or just run one in isolation when you’re debugging — and they’ll still behave the same way. That’s the happiest, lowest-maintenance situation.

Just as importantly, having complex or interdependent tests risks hiding bugs: a tiny issue at the start of the test sequence will cause the whole sequence to fail, so the tests further down aren’t executed at all. As your test suite grows, this is likely to become a bottleneck for your testing journey.

That said, there may be valid exceptions to the rule. In particular, if tests need complex setup that is expensive or impractical to repeat in every single test, it may be warranted to set up a sequential batch of tests. A sequential batch always runs tests in a fixed, predictable order (ordered alphabetically by test name), so it’s okay for a later test to use something the earlier one created (for example: “1. Create a new customer account”, “2. Log in as that new customer”, “3. Place an order”). It still has the drawbacks mentioned above, but may be a reasonable compromise.

The practical rule of thumb:

  • If there is a way to make a test stand alone, make it stand alone.
  • If you do create a deliberate chain, keep it inside one clearly named sequential batch and make sure to never run such tests in any other way.

A little independence goes a long way toward keeping your suite maintainable, reliable, and stress-free.

Handle setup and teardown​

Often, tests need to perform some steps at the beginning to prepare some data (called “setup”), and some at the end to clean up after the test (called “teardown”). These steps are not really part of the test itself, their failure doesn’t indicate a bug was found in the tested feature. Also, these steps are often shared between multiple tests.

For the teardown, use teardown modules. Extract the clean-up steps at the end of a test into a teardown module, or add an existing one to a test in edit mode. A test can have several teardown modules: they sit at the end of the test and run one after another, in the order you set. AIVA runs them even if the test itself failed, and runs all of them even if one fails. Like an authentication module, a teardown module must start with a Navigate to URL step, and it can’t contain an authentication module.

A failed teardown fails the test with the dedicated status Failed in teardown, so you can tell right away whether the problem is in your app or in the clean-up. Teardown modules support module variables, so you can clean up exactly what the test created, for example a user with the email the test signed up with.

For the setup, use a generic module at the start of the test, so several tests can share the same preparation steps.