Hi Squish Users!
Checkout the latest Squish Tip of the Week on our blog:
Squish tip of the week: Isolating Setup from Test Objectives

Isolating the setup, or test pre-conditions, from the objective of the test results in clearer and more accurate testing results.

Remember, a good test case should run without the need to first run a separate test case.
Really? How is that possible if the results of one test are needed for the next test?

Consider the test’s objective
Adding a patient visit logs the visit details in the patient history

Ask yourself
In order to add a patient visit, what must also exist? A patient record.

Verifying the creation of a patient record however is not the objective of the test; however, a patient record must exist prior to a patient visit log being entered.

The patient record then must be part of the test setup. Should an issue occur during the setup, the test should be terminated, as running the test and producing a failed result would be misleading. Such results take longer to filter through and pin-point the true reason for the failure – impacting time now, as well as long term metrics. In the following scenario, if the Given + And do not execute successfully, then the result should log a failure in the setup an not the test’s objective.

Sample Scenario

Scenario: Patient visit logs appear in patient’s history
Given the Patient Portal is running
And the Patient Record exists
When I log a Patient Visit
Then the Patient Visit appear in the Patient History

That does not mean that I never test (1) starting the application or (2) creating a patient record – those would simply be different scenarios or features in separate tests.
How can I avoid having duplicate scripts or test case steps?

By refactoring and breaking apart tests into segments, functions or implementation steps.

The Given and the And statements in the scenario (above) can use shared (or existing) functions…functions also used for scenarios which validate the Patient Portal application can run and the ability to create a Patient Record.

Scenario: The Patient Portal application launches
Given the Patient Portal is installed
When the Patient Portal launches
Then the Patient Portal dashboard should be visible

Scenario: A new patient record exists after adding one entry
Given the Patient Portal is running
When I create a new Patient Record
Then the new Patient Record should be visible in the Patient list
And the Patient History should be blank

Each of the statements in the scenarios above pertain to a set of automated steps, callable functions, using either or a combination of the following two approaches:
  1. Script Test Cases – traditional scripts written in python, perl, javascript, tcl or ruby
  2. or BDD Test Cases – which contain implementation steps, or an automation layer, written in python, perl, javascript, tcl or ruby

Learn more here: