Mittwoch Mai 27, 2009

Best Practices For Software Test Code

Best Practices For Software Test Code

Author: Joerg Sievers – Reviewers: Helge Delfs, Venkatesh Devarajan, Arun Kumar S, Srinivas Kg, Mario Schroeder, Elizabeth Matthis – Revision 10 – Last change: 1. July 2009

Test code is no production code

A well skilled Java developer isn't also a well skilled Java test code developer. The focus of a tester is different to a programmer and also automated test cases are different from methods of production code. They can be written in the same language and they maybe look alike but their goals are different. UI-tests should be more like an acceptance test because it is the same view a customer also has.

Explanation: In desktop environments the production code goal could be not to crash under the most worst circumstances. In test code you should stop working (=controlled, well reported stop of the test case execution) if an error occurs because the subsequent steps would report undefined results. It is easier to get an overview what happened if you only see one, the first error and not hundreds more which depended on the first one.

In web environments the production code goal could be to cloud the executed code in the browser. In test cases the feedback should be best traceable to reproduce simple steps if an error occurs.

Set preconditions

Be sure that a evadable default in the application is really the default in all environments. Otherwise you have to set the settings you need in front of the test case (preconditions). [OOO1]

An automated test case should not depend on other test cases

If you need preconditions to execute a test scenario you have to put in the precondition phase which always runs in front of any test case.

A test case needs to be re-runnable

No test pieces which being created while the test is running should hinder a re-run of the test case. If so, you have to remove such pieces in the precondition phase (=”running it always on the greenfield”). You should write automated software test not user scenario tests with undefined states – that would be another type of tests. Every testcase should have 3 sections: Entry, Action, CleanUp. Entry section will be useful to do any specific pre-settings, Action section is where actual testcase runs, CleanUp section is to undo all the actions performed by that particular testcase.

Use global tool settings and routines instead of own created

If an output path, a timeout, an environment variable, or also a helper method is defined globally it should be used instead of creating them in the test case on your own. This is the same for production and for test code to optimize the maintainability.

Explanation: Especially timeouts often defined in many test cases instead of using divisions or multiplications of the global timeout which is set in the most test tools.

Write test cases readable from top-level like use-cases

In production code the object-oriented approach is best practice. In test code, the focus is to simplify the work-flow of steps executed multiple times. The helper classes and abstraction layers should be made based on this focus but always it should be possible to read the important steps to get a test case done on the top-level and not in sub-routines.[MM01]

Useful feedback

A test case is a step-by-step instruction of a work-flow. In production code, feedback is not given if an action was successful. In test code you should do that more often to be able for others to reproduce these steps manually – and not only those which failed. [MF01]

Use defined prefixes for variables

Modern Integrated Development Environments (IDE) are able to show the type of a variable but for a better reading it makes sense to use defined prefixes. [OOO1] If there is no definition made the “ Hungarian Notation” [ Link English] [ Link German 1] can help.


prefix

type

i or n

integer

i

long

d

single

d

double

s

string

b

boolean

The following prefixes must be combined with an additional prefix:

a

array

g

global (from global.inc)

l

list (for variables declared for use of functions from t_list.inc)

Other naming schemes:

t

testcase

s

sub

f

function


Use clear indicators to show when an action is complete.

When an action has been started and you are waiting for the results, you have to have clear indicators for automated software to show when the action has been completed successfully. If you do not have such an indicator, then you have to use "timeouts", but they are always only a last resort.

For example: You want to load a document. To show that the document has been loaded, the status bar of the application changes or certain buttons become active.

Bibliography

OOO1: Thorsten Bosbach, Helge Delfs, Joerg Sievers, Joerg Skottke, OpenOffice.org Cookbook, 2004

MM01: Marc Michaelis, Boon and Bane of GUI Test Automation, 2008

MF01: Mark Fewster, Dorothy Graham, Software Test Automation, 1999





1The German Wikipedia version has some more tables and descriptions


About

jogi

Search

Archives
« Juli 2014
MoDiMiDoFrSaSo
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
   
       
Heute
Bookmarks