Difference between revisions of "GOOD PROGRAMMING PRACTICES"
m (empty lines removed) |
m (Link to mind map removed) |
||
| Line 1: | Line 1: | ||
<div id="content_view" class="wiki" style="display: block"><span style="font-size: 14px">.................................................................................................................[[Main Page]] / Back to [[Process Patterns]] / Back to [[Test Automation Patterns]]</span><br /> | <div id="content_view" class="wiki" style="display: block"><span style="font-size: 14px">.................................................................................................................[[Main Page]] / Back to [[Process Patterns]] / Back to [[Test Automation Patterns]]</span><br /> | ||
=<span style="font-size: 16px">'''Pattern summary'''</span>= | =<span style="font-size: 16px">'''Pattern summary'''</span>= | ||
| − | <span style="font-size: 16px">Use the same good programming practices for test code as in software development for production code | + | <span style="font-size: 16px">Use the same good programming practices for test code as in software development for production code.</span> |
=<span style="font-size: 16px">'''Category'''</span>= | =<span style="font-size: 16px">'''Category'''</span>= | ||
<span style="font-size: 16px">Process</span> | <span style="font-size: 16px">Process</span> | ||
Revision as of 17:09, 7 May 2018
Pattern summary
Use the same good programming practices for test code as in software development for production code.
Category
Process
Context
This pattern is appropriate when you want your automation scripts to be reusable and maintainable, that is when your test automation is to be long lived.
This pattern is not necessary if you only write short disposable scripts.
Description
Scripting is a kind of programming, so you should use the same good practices as in software development.
Implementation
If you don’t have an automation engineer, have developers coach the automation testers. Important good practices are:
- DESIGN FOR REUSE
- KEEP IT SIMPLE
- SET STANDARDS
- SKIP VOID INPUTS
- INDEPENDENT TEST CASES
- ABSTRACTION LEVELS: Build testware that has one or more abstraction layers.
- Separate the scripts from the data: use at least DATA-DRIVEN TESTING or, better, KEYWORD-DRIVEN TESTING
- Apply the "DRY" Principle (Don’t Repeat Yourself), also known as "DIE" (Duplication is Evil)
Put your best practices in a Wiki so that both testers and developers profit from them.
Potential problems
If the software developers don't use good programming practices, then don't follow them, but investigate good programming outside of your company. (Read books!)
Issues addressed by this pattern
BRITTLE SCRIPTS
BUGGY SCRIPTS
DATA CREEP
GIANT SCRIPTS
HIGH ROI EXPECTATIONS
OBSCURE TESTS
SCRIPT CREEP
TEST DATA LOSS
TOOL-DRIVEN AUTOMATION
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 Process Patterns / Back to Test Automation Patterns
B3 11