Difference between revisions of "KEEP IT SIMPLE"
Line 9: | Line 9: | ||
<span style="font-size: 16px">Use the simplest solution you can imagine. Simple solutions are easier to understand and can thus be reused more often.</span><br /> <span style="font-size: 16px">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. </span> | <span style="font-size: 16px">Use the simplest solution you can imagine. Simple solutions are easier to understand and can thus be reused more often.</span><br /> <span style="font-size: 16px">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. </span> | ||
=<span style="font-size: 16px">'''Implementation'''</span>= | =<span style="font-size: 16px">'''Implementation'''</span>= | ||
− | <span style="font-size: 16px">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.</span><br /> <span style="font-size: 16px">We have already mentioned scripting is also programming, so one should apply this rule also when automating tests.</span> | + | <span style="font-size: 16px">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.</span><br /> <span style="font-size: 16px">We have already mentioned scripting is also programming, so one should apply this rule also when automating tests.</span><br /><br /> |
− | + | <span style="font-size: 16px">Recommendations</span><br /> | |
<span style="font-size: 16px">If you later think of a better solution, then [[REFACTOR THE TESTWARE]]</span><br /> <span style="font-size: 16px">Another pattern to use in this context is [[THINK OUT-OF-THE-BOX]].</span> | <span style="font-size: 16px">If you later think of a better solution, then [[REFACTOR THE TESTWARE]]</span><br /> <span style="font-size: 16px">Another pattern to use in this context is [[THINK OUT-OF-THE-BOX]].</span> | ||
=<span style="font-size: 16px">'''Issues addressed by this pattern'''</span>= | =<span style="font-size: 16px">'''Issues addressed by this pattern'''</span>= |
Revision as of 11:20, 28 June 2018
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
INEFFICIENT FAILURE ANALYSIS
MANUAL MIMICRY
OBSCURE TESTS
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