Implementing tests

As the number of tests grows, it is important to be able to differentiate tests. If you can deduce information from the test name, you avoid wasting time while searching for a specific test.

Consider the following points:

  • Use good naming conventions to name your tests.
  • Create logical folder structures to store your tests.
  • Create parameterized tests that are driven from spreadsheets or other data sources. The data that is defined in spreadsheets can cover as many test cases as possible, reducing the number of tests to implement.
  • Creating repeating tests can take time. When you are creating tests, define a template if a test is repeatedly created.
  • Link your tests to message requirements as far as possible. When you are linking requirements to tests, a change in the requirement propagates the changes automatically into your tests.

Some automation tests can become complicated and difficult for your colleagues to understand. They are also more tedious to debug.

Use the following tips to avoid confusion:
  • Write your tests as generically as possible.
  • Create common function or subfunction tests that can be called by various parent tests by using the Run Test action. This reduces duplication and errors.
  • Use the Business View to add meaningful descriptions of what each action in a test does.
  • Use the Comment action to describe difficult steps in a test and to offer clarity.
  • Use the Documentation tab of a test to add a description of its functionality.
A new, empty test always consists of three basic phases: initialize, test steps and tear-down. The essential usage of these phases is as follows:
  • The initialize phase can be restricted to running commands that start or configure plug-ins, servers, or target resources. This phase can be used for test preparation (for example, populating environment variables). However, if these variables are overwritten in the test steps, they are not restored to their original values.
  • The test steps phase can contain the actions that are used in the test. If the test is part of a repeated or concurrent execution (by using a stub or a performance test), the test steps phase is the only one that is run for each iteration.
  • Similar to initialization, the tear-down phase can be used only for deallocation of resources, termination of processes, and so on. The tear-down phase is run only by the last test to be processed when run repeatedly or concurrently.