DEFAULT DATA

From Test Automation Patterns
Revision as of 15:53, 21 August 2018 by Dorothy (talk | contribs) (→‎Experiences)
(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

Use default data to simplify data input

Category

Design

Context

This pattern is useful when test cases need a lot of common data that is not all meaningful for the specific test.

Description

Instead of cluttering test cases with data that is needed, but is not relevant for the specific test, use default data.

For example, if you are interested in testing validation for a Name field but don't care about the contents of the address or phone number fields, set up a default value for the address ("123 Main Street") and phone number. Then in your test, you will say what the Name field should contain, but not what the other fields should contain, so your framework will copy the default values (because if they were left blank, the test would fail) to those fields.

Implementation

Prepare default data. Your TEST AUTOMATION FRAMEWORK substitutes default data for missing data during the data inputs in the test cases

Potential problems

Default values should be valid, but there may be combinations of other values that make a normally valid value invalid.
You may end up with a lot of people living at the same address… ;-)

Issues addressed by this pattern

DATA CREEP

Experiences

Thanks to Richard Bradshaw, whose pattern DATA BUILDER inspired this one.

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 Process Patterns / Back to Test Automation Patterns