Squish tip of the week: Isolating Setup from Test Objectives

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:

  • Script Test Cases – traditional scripts written in python, perl, javascript, tcl or ruby
  • or BDD Test Cases – which contain implementation steps, or an automation layer, written in python, perl, javascript, tcl or ruby

Learn more

froglogic_cropped