Create a Ghost Inspector Test

Overview

We often do not simply QA something once. As tasks are completed and more QA is done, we need to re-test that existing features don’t break from changes - regression testing. Writing a test in

is a way to automatically regression test certain features.

tests are automated and are simply running through a list of instructions. Because of this, specificity is important - the tool must know clearly exactly what actions to do and where on the page. A test failing can be from the test steps themselves becoming invalidated just as often as a true problem.

Who can do this

You will need access to our studio

account. This is a task best suited for a developer or QA engineer. If you’re writing a test based on a recent task or project, it’s strongly recommended the relevant developer or QA engineer are involved in test creation.

What you need

  • Access to Ghost Inspector by logging in with the Studio email account.
  • An understanding of the scope of the test (”What are we checking for, exactly?”)

Steps

Creating the Module

Create and name the module in the appropriate location

All our tests start as modules - tests that we don’t run themselves, but rather import into another suite for execution. Our projects should have a clearly-labeled place where modules go. Locate this folder, choose a suite of modules that’s appropriate to the test you’re looking to perform, and clearly name your new test.

Example: You are wanting to test that a module opens and closes successfully on Project A. You go to Project A’s organization in Ghost Inspector. Inside a Modules folder is a test suit labeled “Modules, Pops-Ups, and Widgets”. You open this suite and create your test: “Contact Us module opens and closes correctly”.

Consider the steps for a successful test

For example, if our test is to check that a modal opens and closes properly, we might break the task down into very specific actions:

  1. Check that the modal is not present on the page at the start.
  2. Click the button that opens the modal.
  3. Check that the modal is now present on the site.
  4. Click the button that closes the modal.
  5. Check that the modal is no longer present on the site.
Begin creating the test in Ghost Inspector

Using Ghost Inspector’s browser extension, along with manual editing of the test steps, construct a test that matches the outline considered. This will involve actions to perform, and results to assert.

👻
Assertions are important for the test! Assertions are how we know the test failed: if an assertion is not true, then the test has failed somehow and we aren’t getting the results we’re expecting.

Ghost Inspector needs to know the exact elements to act or assert on. It identifies these elements through CSS selectors. You must make sure you have an accurate and clear CSS selector for the exact element you want to interact with. A mis-written selector might result in Ghost Inspector not being able to find the element, or interacting with a different element entirely. Your browser’s page inspection tools can help identify the CSS selector for specific HTML elements.

A list of steps for opening, closing, and checking a modal. The modal is identified with the modal-container CSS class. The button to open the modal has a complex CSS selector.
A list of steps for opening, closing, and checking a modal. The modal is identified with the modal-container CSS class. The button to open the modal has a complex CSS selector.
Confirm the test works correctly

Give it a test run. If it fails, correct issues until the test returns expected behavior. Ghost Inspector automatically creates videos of the script running through the page: watching it may be useful for both identifying problems and understanding how the script works.

Adjust any URLs in the test to the baseURL variable

We make our tests modules so that we can run them in multiple URLs. If we wrote a test that checks subdomain1.cantilever.co specifically, it’ll be of no help if we wanted to run the same test on subdomain2.cantilever.co.

To get around this, we replace URLs with a variable. Each test suite then fills this variable with the correct url for where it should be ran. Our standard name for this variable is baseURL.

This module’s URLs have been replaced with a {{baseURL}} variable. This variable will be filled in with the appropriate domain, depending on what suites import it.
This module’s URLs have been replaced with a {{baseURL}} variable. This variable will be filled in with the appropriate domain, depending on what suites import it.
The suite that runs the test has a baseURL variable defined.
The suite that runs the test has a baseURL variable defined.
Set the test as an import-only

On the test’s page, click Settings, then Modularization on the sidebar. Check the box to set the test as a module.

image

If you are creating multiple tests at once, it can sometimes be easier to go to the Suite page, select the relevant tests, and use the Bulk Actions command to set them all as import-only immediately.

image

Importing to Run the Test

If necessary, create a new suite

The suite should be appropriately named based on its purpose (”Staging Smoke Test”, “Screenshot Tests”, etc.) and placed in the appropriate folder for test execution suites.

Make sure to set the baseURL variable on the suite level.

Go through the settings to ensure the suite is configured correctly for its purpose. This includes scheduling, notifications, any default assumptions such as an HTML user/pass for logging in, screen size, etc.

Create a new test in the appropriate suite

Set the start URL of the test as appropriate, remembering to use the baseURL variable.

image
Add a step to the test to import the appropriate module