Difference between revisions of "VERIFY-ACT-VERIFY"
(Topic titles in capital letters) |
|||
Line 32: | Line 32: | ||
''<span style="font-size: 16px">[[FALSE PASS]]</span>''<br /> ''<span style="font-size: 16px">[[FLAKY TESTS]]</span>'' | ''<span style="font-size: 16px">[[FALSE PASS]]</span>''<br /> ''<span style="font-size: 16px">[[FLAKY TESTS]]</span>'' | ||
=<span style="font-size: 16px">'''Experiences'''</span>= | =<span style="font-size: 16px">'''Experiences'''</span>= | ||
− | <span style="font-size: 16px">If you have used this pattern, please | + | |
+ | <span style="font-size: 16px">If you have used this pattern and would like to contribute your experience to the wiki, please go to [[Experiences]] to submit your experience or comment.</span><br /> <br /> | ||
+ | |||
+ | |||
+ | span style="font-size: 14px">.................................................................................................................[[Main Page]] / Back to [[Design Patterns]] / Back to [[Test Automation Patterns]]</span><br /> <br /> <span style="font-size: 14px">[*] This pattern was suggested by the testing team at BREDEX - Thanks very much!</span></div> |
Revision as of 09:35, 5 July 2018
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
Experiences
If you have used this pattern and would like to contribute your experience to the wiki, please go to Experiences to submit your experience or comment.
[*] This pattern was suggested by the testing team at BREDEX - Thanks very much!