Difference between revisions of "CHAINED TESTS"

From Test Automation Patterns
Jump to navigation Jump to search
 
(One intermediate revision by the same user not shown)
Line 15: Line 15:
 
''<span style="font-size: 16px">[[LONG SET-UP]]</span>''
 
''<span style="font-size: 16px">[[LONG SET-UP]]</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 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!</span><br /> <span style="font-size: 14px">.................................................................................................................[[Main Page]] / Back to [[Design Patterns]] / Back to [[Test Automation Patterns]]</span></div>
+
 
 +
<span style="font-size: 16px">If you have used this pattern and would like to contribute your experience to the wiki, please go to [[Feedback]] 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></div>

Latest revision as of 15:51, 21 August 2018

.................................................................................................................Main Page / Back to Design Patterns / Back to Test Automation Patterns

Pattern summary

Automate the tests so that they run in a predefined sequence.

Category

Design

Context

Use this pattern when tests need a very long setup. If possible avoid it

Description

You automate the tests so that they run in a predefined sequence. Each test generates the initial conditions for the following ones so that you have to do the set-up only once.

Implementation

You leave the Software Under Test (SUT) as is after each test, but before you start the next test you check that the expected initial conditions are really met (the preceding tests could have failed).
Another way to avoid a long set-up for every test case is to use a SHARED SETUP that is set-up before your tests run. Each test cleans up after it is run so that the next tests can start with a clean fixture.

Potential problems

Avoid this pattern if you don’t want to get the issue INTERDEPENDENT TEST CASES

Issues addressed by this pattern

LONG SET-UP

Experiences

If you have used this pattern and would like to contribute your experience to the wiki, please go to Feedback to submit your experience or comment.

.................................................................................................................Main Page / Back to Design Patterns / Back to Test Automation Patterns