Patterns for Scripted Acceptance Test-Driven Development
Download as PPTX, PDF0 likes573 views
The document provides patterns for acceptance test-driven development (ATDD) using scripts, addressing the challenges of test creation and execution in software development. It outlines various test patterns, including flow creation, object management, limits testing, and templating, with solutions to enhance clarity and maintainability. Additionally, it emphasizes the importance of client involvement in reviewing tests to prevent errors and ensure understanding.
Patterns for Scripted Acceptance Test-Driven Development
- 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
- 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
Editor's Notes
- #20: 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.
- #21: 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
- #22: 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"
- #24: # script 1executeScript sampleDatabaseSetup.txt… and then do the tests you want# script 2executeScript sampleDatabaseSetup.txt… and then do a number of different tests
- #25: # the tests below should be unit testsexpect 25 getBQueueNodeFatherIndexexpectError “Code #432653: unexpected fault for the middleware connection”getCORBASkeletonMiddlwareProperty