Difference between revisions of "KEEP IT SIMPLE"
Jump to navigation
Jump to search
m (Topic titles in capital letters) |
|||
| (3 intermediate revisions by 2 users not shown) | |||
| 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>= | ||
<span style="font-size: 16px">''[[COMPLEX ENVIRONMENT]]''</span><br /> <span style="font-size: 16px">''[[DATA CREEP]]''</span><br /> ''<span style="font-size: 16px">[[DATE DEPENDENCY]]</span>''<br /> <span style="font-size: 16px">''[[HARD-TO-AUTOMATE]]''</span><br /> ''<span style="font-size: 16px">[[INEFFICIENT FAILURE ANALYSIS]]</span>''<br /> ''<span style="font-size: 16px">[[MANUAL MIMICRY]]</span>''<br /> ''<span style="font-size: 16px">[[OBSCURE TESTS]]</span>''<br /> ''<span style="font-size: 16px">[[SCRIPT CREEP]]</span>'' | <span style="font-size: 16px">''[[COMPLEX ENVIRONMENT]]''</span><br /> <span style="font-size: 16px">''[[DATA CREEP]]''</span><br /> ''<span style="font-size: 16px">[[DATE DEPENDENCY]]</span>''<br /> <span style="font-size: 16px">''[[HARD-TO-AUTOMATE]]''</span><br /> ''<span style="font-size: 16px">[[INEFFICIENT FAILURE ANALYSIS]]</span>''<br /> ''<span style="font-size: 16px">[[MANUAL MIMICRY]]</span>''<br /> ''<span style="font-size: 16px">[[OBSCURE TESTS]]</span>''<br /> ''<span style="font-size: 16px">[[SCRIPT CREEP]]</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 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:55, 21 August 2018
.................................................................................................................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
INEFFICIENT FAILURE ANALYSIS
MANUAL MIMICRY
OBSCURE TESTS
SCRIPT CREEP
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.