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!