KEEP IT SIMPLE

From Test Automation Patterns
Revision as of 09:11, 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

Use the simplest solution you can imagine.

Category

Design

Context

This pattern should be adopted for long lasting automation but also when writing disposable scripts.

Description

Use the simplest solution you can imagine. Simple solutions are easier to understand and can thus be reused more often.
Use this pattern especially when automating manual tests: often automation tools let you easily do things (like for instance getting information directly from a database) that a manual tester cannot replicate.

Implementation

One of the rules of extreme programming is simplicity, that is one should implement just what one needs now, no more and no less. The reasoning behind this rule is that mostly when you implement something because you may need it later, the later never comes up or if it does, it is completely different from what you expected so that you worked for nothing.
We have already mentioned scripting is also programming, so one should apply this rule also when automating tests.

Recommendations

If you later think of a better solution, then REFACTOR THE TESTWARE
Another pattern to use in this context is THINK OUT-OF-THE-BOX.

Issues addressed by this pattern

COMPLEX ENVIRONMENT
DATA CREEP
DATE DEPENDENCY
HARD-TO-AUTOMATE HARD-TO-AUTOMATE
INEFFICIENT FAILURE ANALYSIS
MANUAL MIMICRY MANUAL MIMICRY
OBSCURE TESTS OBSCURE TESTS
SCRIPT CREEP SCRIPT CREEP

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