Your SlideShare is downloading. ×
  • Like
Patterns for Scripted Acceptance Test-Driven Development
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.


Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Patterns for Scripted Acceptance Test-Driven Development


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 …

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.

Published in Education , Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads


Total Views
On SlideShare
From Embeds
Number of Embeds



Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

    No notes for slide
  • Example:In a Monopoly game, you need to test if a player is thrown out of the game afterfalling on a series of tax places and taking a series of actions that decrease hismoney. If you use tables, you will need a separate table for every command you use.
  • Example:generateReport output="report.txt"# equalFiles is a command in EasyAccept that tests if# two files have the exact same contentequalFiles templates\\reportTemplate.txt report.txt
  • Example:# creating an employee - script1.txtclearEmployeeDatabaseexpecterror "employee doesn't exist" getEmployeeSalary \\employeeName="John Doe"createEmployeeemployeeName="John Doe" salary=1500expect 1500 getEmployeeSalaryemployeeName="John Doe"saveEverythingAndCloseProgram# restart is an EasyAccept commandrestart# checking persistenceexpect 1500 getEmployeeSalaryemployeeName="John Doe"
  • # script 1executeScript sampleDatabaseSetup.txt… and then do the tests you want# script 2executeScript sampleDatabaseSetup.txt… and then do a number of different tests
  • # the tests below should be unit testsexpect 25 getBQueueNodeFatherIndexexpectError “Code #432653: unexpected fault for the middleware connection”getCORBASkeletonMiddlwareProperty


  • 1. Patterns for ScriptedAcceptance 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. ContextATDD 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 PatternsTest Flow Creator Destroyer Limit Command TableBreaker Errors TesterWorkflow 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 CheckObject 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 nothingObject 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 dont. 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 TemplateAssertion 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