Search our documentation:
Ghost Inspector's test editor provides you with the ability to manage all the steps in your test, including adding, reordering and removing steps. It is accessible by clicking the "Edit Steps" button when viewing your test.
Tests are often created with our test recorder first, then edited. However, tests can also be built from scratch. The test editor displays each test step as a block with options for adding, removing and moving each step. Drag and drop is supported for re-ordering test steps.
The dropdown menu on the bottom, left contains the action associated with the step. This dictates whether the step is performing an operation such as clicking an element, making an assertion, extracting a value into a variable, and so on. There is a wide range of actions available.
When a step involves interacting with an element on the page, for instance clicking a button, our system targets that element using CSS or XPath. The selector for the target element is entered into the "Element selector" input at the top of the step.
Certain actions will present additional fields for the step. For instance, an "Assign" step will present a field for inputing the value to assign to the element you are targeting — or add a file to be uploaded into a
Each step can be made optional, if you choose. This means that the test will continue execution, even if the step fails. This can be useful in situations when dealing with behavior that only occurs a portion of time, like a modal dialog popping up. Each step also has a field for adding notes so that you can document any necessary details. Step notes are displayed within the test results.
Operations include the standard actions that a typical user will carry out on a webpage.
<input type="text">element or a
<select>element. This operation is also used for file uploading.
Enteron an element.
5000will pause the test for 5 seconds. (It's typically more efficient to leverage Ghost Inspector's implicit waiting to ensure a condition has been met. Consider controlling the flow of your test with an assertion instead.)
Navigation actions include two straightforward operations for navigating to a page and refreshing.
Assertions allow you to confirm that a certain condition is met on the page. Assertions are not required, but they are highly recommended. Using at least one assertion at the end of your test is generally a good idea because it helps to confirm that things have turned out as expected.
To understand the importance of assertions, consider a simple test that fills in "Username" and "Password" fields, then clicks a "Login" button and finishes. The expectation is that the test will perform a successful login. However, even if clicking the "Login" button causes an error and the user isn't logged in, the test will still pass because it's just submitting the form then exiting. It's not actually performing any checks on the outcome of the login operation. If an assertion were added to the end of that test to make sure the page is displaying "Dashboard" (something that only happens once the user is successfully logged in), then the test is far more useful — because it will fail if the login fails to bring the user to the dashboard screen.
In the same way, assertions are incredibly useful for controlling the flow of your tests. Assertions let you avoid hardcoded "Pause" steps because they will continue checking the condition and waiting for it to be true.* This forces the test to wait for the situation that you are expecting before continuing on. Reusing the example above, assume that you want your test to log into your application, then navigate to a URL that you've specified afterwards. If you simply click the "Login" button and then use a "Go to URL" step to navigate away, the browser may navigate away before the login operation completes. You might be tempted to add a 10 second "Pause" step to wait for the login to complete. However, it's much more effective to add an assertion step to confirm that the login has completed. Once again, you could add an assertion to make sure the page is displaying "Dashboard" (something that only happens once the user is successfully logged in). This will ensure that the login has completed before executing the navigation step and doesn't depend on an arbitrary "guess" of 10 seconds with a "Pause" step.
* Assertions will continue checking for the condition for the time specified by the Element Timeout setting. This is sometimes referred to as "implicit waiting". The default is 15 seconds, but this can be increased to allow assertions to spend more time checking for the condition.
displaystyle attribute set to
visibilitystyle attribute set to
hidden. It will fail if the element is not visible.
returnstatement. This will pass if the return value is "truthy" and fail if the return value is "falsy". We recommend using return values of
These actions allow for the creation of variables within your test.
All valid CSS selectors are supported, including attribute selectors which can be quite useful. You can also target elements based on their text contents (instead of IDs, classes and attributes) using XPath. For instance, a link with text "Dashboard" could be targeted using
//a[contains(text(), "Dashboard")] which is often more simple and clear than using classes or the URL of the link.
Our test recorder will generate unique CSS selectors for each step designed to target the exact element that you interacted with while recording. Because our extension does not have any specific knowledge of your website or it's DOM, it's often beneficial (and highly encouraged) to review the generated CSS selectors after saving a test to look for areas where they can be simplified for clarity and durability.
If you're looking to generate a unique CSS selector for an element outside of our recording extension, Chrome offers options when you right click on elements in the developer console:
Ghost Inspector's test editor allows you to setup "Network Filters" that can perform an action when a specific network request is encountered. This section appears below the steps in your test.
A network filter takes a regular expression for matching specific URLs and provides some actions that can be taken when that URL is encountered. You can choose to block the request by checking off the "Skip request" option. You can also choose to exit the test with either a pass or a fail status.
You may apply as many network requests as you would like. They are useful for blocking access to analytics, retrieving OAuth tokens, and various other tasks.