1

Patterns for ScriptedAcceptance Test-Driven

DevelopmentFang Liu

Ider ZhengPooja Gore

2

Patterns for acceptance test-driven development (ATDD) using scripts

Approaches to cope with the challenges

Intent

3

ATDD consists of

Script Languageso Allows control of one or more application

Business objectso manipulated by the program which make sense to the

cliento hidden to the client

Non-Business Objects

Context

4

Client must understand and review the testso Should be imbued with a testing cultureo A learning curve is associated with the

approach

Problem

Interrelated Patterns

Test Creation Patterns

Test Flow Creator Destroyer

Limit Breaker

Command Errors

Table Tester

Workflow Tester

Template Tester

Persistence Tester

To verify if a given software property results as expected after a given action

Test Flow

Step 1:o Build a scenario you want to test

Step 2:o Operate the program with the desired action

Step 3:o Check the new program’s state.

Three Steps for Test Flow

To test if a business object has been successfully created or removed in the program

Business object creation and destruction are common operations in test scripts

Creator & Destroyer

Steps for Construction

Check Object Not

Exist

• Otherwise, exception or do nothing

Create Object

Check Object Exist

• Otherwise, exception or go back creation step

Validate the

property of Object

Steps for Destruction

Check Object Exist

• Otherwise, do nothing

Destroy Object

Check Object Not

Exist

• Otherwise, exception or go back destroy step

Validate double

Destruction

To test a business object or program flow that has limits (ranges or sets of allowed values)

Limit Breaker

Always precisely demarcate limits by giving examples of inner and outer bounds.

Make sure values immediately out of the bounds throw errors, and limit inbound values don't.

In general, tests for the immediate limits are enough to indicate to the developer that further values aren’t acceptable, even if the tests don’t explicitly list all of them.

Limit Breaker

Created a new command to incorporate in the script language and will start writing tests with it

Command Errors

Test coverage is difficult to attain if you don’t approach testing systematically

When thinking on a new command to add to the script language, you often think about tests that will involve this command, including anomalous uses;

A system should be able to identify a misuse of one of its operations and may even give clues about the problem cause

Command Errors

To test extensive lists of features for multiple business objects of the same kind, or multiple examples to test formulas (calculations)

To declare business rules in a formulaic manner

Table Tester

Table Tester

Context Test a workflow

Problemo Tables become too verboseo Such tables make script understanding and maintenance

difficult

Forces

A workflow is sequential in nature

Solution Use commands in sequence instead of tables

Workflow Tester

Context

Testing massive textual or non-textual content

Problemo Massive textual content makes a script unintelligibleo Non-textual content can only be included in a script through an IDE

Forces

Templates for test cases can be generated using software

Solutiono Divert the contents to be tested to outside the script o And use a template to compare it with

Related Patterns

Test Flow

Template Tester

Context Test if data entered in the program is persistent

Problem

Lack of a systematic approach to testing persistence

Forces

Setting up a scenario for persistence can often be reused

Solutiono The first part, add data in a programo The second part , check if data is retained

Related Patterns

Test Flow

Persistence Tester

Build Summarize

r

Only Business Objects

Commentor

Test Organization Patterns

Context

Similar test used frequently in a script

Problem Repetition of the same test sequence, making script

verbose

Forces

Commonly used sequence can be summarized in an expressive command

Solution

Set commonly used tests a separate single test sequence

Build Summarizer

Context Tests include Non-business objects

Problem

Tests for non-business objects are unintelligible for the client

Forceso Client’s understanding of all Tests is importanto Testing non-business objects is equally important

Solutiono Test only business objects in an acceptance test scripto Test all Non-Business Objects with Unit Test

Only Business Objects

Context

Developer fails to understand a designed test

Problemo Development stalls o A bug or wrong requirement may be introducedo Inconsistent Test Comments

Forces

Communicator between Client and Developer

Solutiono Use Commentso Update Comments

Commentor

Client Assertion

TemplateGenerato

r

Test Application Patterns

27

Contexto Find a potential wrong test

Problemo If bugs are changed by developers, feature creep will

emergeo If bugs are not found, clients disappointed

Forceso Clients must review tests

SolutionsNo test should be modified without the client’s consent

Client Assertion

28

Context

Problemo Becomes harder to find test cases

Solution Exam the presented results

Template Generator

Most widely known o FIT (Framework for Integrated Testing)

Otherso EasyAccepto Exactor

Testing tools

30

THANK YOU!