VERIFY-ACT-VERIFY

From Test Automation Patterns
Revision as of 10:23, 4 April 2018 by Cathal (talk | contribs) (Created page with "<div id="content_view" class="wiki" style="display: block"><span style="font-size: 14px">.........................................................................................")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search
.................................................................................................................Main Page / Back to Design Patterns / Back to Test Automation Patterns

Pattern summary [*]]

The action to test is surrounded by two verifications that check the initial and final state (pre- and post-conditions).
This pattern ensures that a test actually checks whether a function works as expected, and a failure isn't due to some other factor (e.g. data consistency during creation / update or deletion of objects).

Category

Design

Context

This pattern is especially useful for long term automation, but it can be used also for short lived tests.

Note that if you do a FRESH SETUP for every test case you will not really need this pattern since you supposedly set up consistent initial conditions

Description

Using this pattern lets you ensure that the function you are testing actually works in the desired way. The pattern reminds you to check that the tested action triggers the right state transition. A test without verifications may not detect a problem if e.g. the steps to perform an action were successful but the action itself wasn’t (e.g. the individual actions to create a customer were successful, but the saving to the database failed).

Implementation

The action to test in the test case is surrounded by two verifications that check the initial and the final state (verify-act-verify).
The advantages of using this pattern are:

  • Higher detection rate of defects in functions
  • Well-structured test cases --> Tester cannot forget a verification
  • Easy to use


Examples:

  • Create a new user
    • Verify that the user does not already exist
    • Create the user
    • Verify that the new user exists
  • Update an existing user account
    • Verify that the user does not already exist
    • Create the user
    • Verify that the new user exists
  • Delete a user
    • Verify that the user already exists
    • Delete the user
    • Verify that the user is deleted

Potential problems

  • May not applicable for every type of use case (e.g. testing search functions may not be suitable for VAV)
  • May increase the size and execution length of tests that require relatively complex verifications for simple actions

Issues addressed by this pattern

FALSE PASS
FLAKY TESTS

Experiences

If you have used this pattern, please add your name and a brief story of how you used this pattern: your context, what you did, and how well it worked - or how it didn't work!
.................................................................................................................Main Page / Back to Design Patterns / Back to Test Automation Patterns

[*]] This pattern was suggested by the testing team at BREDEX - Thanks very much!