introduces a series of related patterns to be used in an acceptance testdrivendevelopment (ATDD) approach to software development using scripts. ATDDuses executable client-readable acceptance tests written in the form of scripts as thekey analysis artifacts that guide software development and presents a number ofadvantages over traditional analysis artifacts – texts and diagrams. They include abetter bridging of communication gaps between clients and developers, prevention offeature creep and synchronization between analysis changes and the code beingwritten.

1. Patterns for Scripted
Acceptance Test-Driven
Development
Fang Liu
Ider Zheng
Pooja Gore
1

2. Intent
 Patterns for acceptance test-driven development
(ATDD) using scripts
 Approaches to cope with the challenges
2

3. Context
ATDD consists of
 Script Languages
o Allows control of one or more application
 Business objects
o manipulated by the program which make sense to the client
o hidden to the client
 Non-Business Objects
3

4. Problem
 Client must understand and review the tests
o Should be imbued with a testing culture
o A learning curve is associated with the approach
4

5. Interrelated Patterns

6. Test Creation Patterns
Test Flow Creator Destroyer
Limit Command Table
Breaker Errors Tester
Workflow Template Persistence
Tester Tester Tester

7. Test Flow
 To verify if a given software property results as
expected after a given action

8. Three Steps for 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.

9. Creator & Destroyer
 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

10. Steps for Construction
Check
Object Not •Otherwise, exception
or do nothing
Exist
Create
Object
Check •Otherwise, exception
or go back creation
Object Exist step
Validate the
property of
Object

11. Steps for Destruction
Check •Otherwise, do
nothing
Object Exist
Destroy
Object
Check •Otherwise, exception
Object Not or go back destroy
step
Exist
Validate
double
Destruction

12. Limit Breaker
 To test a business object or program flow that has
limits (ranges or sets of allowed values)

13. 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.

14. Command Errors
 Created a new command to incorporate in the script
language and will start writing tests with it

15. 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

16. Table Tester
 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

17. Table Tester

18. Workflow Tester
 Context
Test a workflow
 Problem
o Tables become too verbose
o Such tables make script understanding and maintenance difficult
 Forces
A workflow is sequential in nature
 Solution
Use commands in sequence instead of tables

19. Template Tester
 Context
Testing massive textual or non-textual content
 Problem
o Massive textual content makes a script unintelligible
o Non-textual content can only be included in a script through an IDE
 Forces
Templates for test cases can be generated using software
 Solution
o Divert the contents to be tested to outside the script
o And use a template to compare it with
 Related Patterns
Test Flow

20. Persistence 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
 Solution
o The first part, add data in a program
o The second part , check if data is retained
 Related Patterns
Test Flow

21. Test Organization Patterns
Build Only Business
Summarizer Objects
Commentor

22. Build Summarizer
 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

23. Only Business Objects
 Context
Tests include Non-business objects
 Problem
Tests for non-business objects are unintelligible for the client
 Forces
o Client’s understanding of all Tests is important
o Testing non-business objects is equally important
 Solution
o Test only business objects in an acceptance test script
o Test all Non-Business Objects with Unit Test

24. Commentor
 Context
Developer fails to understand a designed test
 Problem
o Development stalls
o A bug or wrong requirement may be introduced
o Inconsistent Test Comments
 Forces
Communicator between Client and Developer
 Solution
o Use Comments
o Update Comments

25. Test Application Patterns
Client Template
Assertion Generator

26. Client Assertion
 Context
o Find a potential wrong test
 Problem
o If bugs are changed by developers, feature creep will emerge
o If bugs are not found, clients disappointed
 Forces
o Clients must review tests
 Solutions
 No test should be modified without the client’s consent
27

27. Template Generator
 Context
 Problem
o Becomes harder to find test cases
 Solution
 Exam the presented results
28

28. Testing tools
 Most widely known
o FIT (Framework for Integrated Testing)
 Others
o EasyAccept
o Exactor

29. THANK YOU!
30