AireAssert

Appearance

Getting Started with AireAssert ​

This guide will walk you through creating your first AireAssert test for an AireForm.

You'll learn:

  • How to setup AireAssert for testing
  • The structure of an AireAssert Test Set
  • How to write a basic AireForm test

Getting Access ​

  1. Visit the AireAssert site and log in using your email address.

  2. Check the left-hand panel under Repositories. If no repositories are listed, contact your administrator. They can assign a repository directly to you or add you to the appropriate user group.

Creating Your Test Set and Feature File ​

See the Repositories Tree View section

Writing Your First Feature (Test) ​

A feature file is a human-readable collection of test commands that not only exercise your form but also document its behaviour.

Note: Feature files use Gherkin syntax, but AireAssert supports only a subset of Gherkin. You may only use the commands provided in the Command Library.

AireAssert includes a built-in feature-file editor (see Using the Test Editor), though you’re free to use any text editor you prefer.

Create a new file named bmi-reporting.feature (or use a name that matches your form) inside the Features folder, and populate it with the following content:

json
Feature: BMI Reporting
   The BMI Reporting form allows patients to submit their height and
   weight information instead of having to visit a doctors surgery

Scenario: Underweight Patient
    Given we are completing the bmi-reporting eform
    When we set 'Height (m)' to '2'
    And we set 'Weight (kg)' to '60'
    Then the 'BMI' form section is visible
    And 'BMI' shows '15'
    And 'Weight appropriate' shows 'Underweight'

Let’s break down each part of the *.feature file:

  1. Feature Title
    The first line (Feature: …) is simply a human-readable title.

  2. Optional Description Block
    You can add one or more lines of descriptive text beneath the title to explain the behaviour you’re defining. This is not required, but it’s highly recommended for documentation purposes.

  3. Scenario(s)
    A single feature file can contain multiple scenarios. Each scenario represents a discrete test case.

    • GIVEN
      Always begins with a Given step, which loads the form under test. The form name should match the URI segment you’d see in your browser.

    • WHEN / THEN

      • A When step represents an action or interaction with the form (e.g., clicking a button, entering text).
      • A Then step performs an assertion, verifying that the form reacted as expected.

    Because the file reads like plain English, you can “walk through” the scenario on the live form to see exactly what each step does.

Tips & Gotchas ​

  • Field Labels:
    You refer to form fields by their labels. If a label contains a single quote ('), omit the quote in your test.

    gherkin
    # Label: My item’s date
# Test step:
When I enter "2025-01-01" into the field "My items date"

  • Field IDs: If you prefer, you can reference fields by their underlying ID instead of the visible label.

  • Case Sensitivity: Field labels are case-sensitive—make sure your steps match the exact casing of the form labels.

Pushing Your Changes ​

Push your changes to the Test Sets repository back to Git so they can be picked up by the application.

Running Your Test ​

Refer to the Running a Test Set section.

Next Steps ​

Review the available test commands in the Command Library section.