Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Improving Batch-Process Testing Techniques with a Domain-Specific Language

532 views

Published on

Slides used at the JavaOne 2011 session.

Published in: Software, Technology
  • Be the first to comment

Improving Batch-Process Testing Techniques with a Domain-Specific Language

  1. 1. Improving Batch-Process Testing Techniques with a Domain-Specific Language Alberto Lemos (Dr. Spock) Senior Software Architect SpockNET Danival Taffarel Calegari MATERA Systems Architect Globalcode Instructor
  2. 2. Agenda • Principles & Proposals • Why to use a DSL to test? • 2 Case Studies
  3. 3. Objective “Show a simple way to improve batch process tests with a Domain-Specific Language”
  4. 4. Motivation • Test automation contributes to the project success • It is hard and time consuming to write and automate tests • It is more complex and hard to write tests for batch process
  5. 5. Agenda • Principles & Proposals • Why to use a DSL to test? • 2 Case Studies
  6. 6. Principles for a good Test Automation • Automated tests must be: • Easy to write • Easy to run • Self-contained • Run quickly • Always updated
  7. 7. Challenges to test a Batch Process • How to test Batch Process? • How to control when it starts or stops? • How to prevent concurrent run? • The preparation and validation steps require lots of complex SQLs
  8. 8. Domain-Specific Language • Why to use DSL to test? • A good DSL must be: • Expressive and natural • Easy to use and learn • Hard to misuse • Extensible
  9. 9. Agenda • Principles & Proposals • Why to use a DSL to test? • 2 Case Studies
  10. 10. Making test writing easier with DSL • Define a language specifically to write the tests • The language must be closer to the business than to the technology • The easier the DSL, the greater the chance to it will be used
  11. 11. Making test writing easier with DSL • The DSL implementation strategy in 2 steps: • 1st step: Use Internal (embedded) DSL • 2nd step: Use external DSL
  12. 12. Internal (embedded) DSL • It is easier to write • It has tool support • It provides a good fluency for those who know the underlining programming language.
  13. 13. External DSL • It has less technological limitations • It adds more value per line of code • It can be used by a layman
  14. 14. Steps for DSL Setup Create a basic infrastructure to run the processes and verify the results. Create a DSL for each functionality Write the test for the functionality
  15. 15. Steps for DSL Setup
  16. 16. Steps for DSL Setup • How can I run a batch in an isolated form?
  17. 17. Steps for DSL Setup • How can I run a batch in an isolated form? • How should the test code to run the SQL to verify the results?
  18. 18. Steps for DSL Setup • How can I run a batch in an isolated form? • How should the test code to run the SQL to verify the results? • How to make the DSL open a browser, do login and press buttons?
  19. 19. Steps for DSL Setup
  20. 20. Steps for DSL Setup • Use the builder pattern
  21. 21. Steps for DSL Setup • Use the builder pattern • Provide default values or they will be automatically generated
  22. 22. Steps for DSL Setup • Use the builder pattern • Provide default values or they will be automatically generated • Provide an abstract base class to be extended
  23. 23. Steps for DSL Setup • Use the builder pattern • Provide default values or they will be automatically generated • Provide an abstract base class to be extended • Reuse similar functionalities
  24. 24. Agenda • Principles & Proposals • Why to use a DSL to test? • 2 Case Studies
  25. 25. Case studies • Application of the techniques in two global bank systems with strong batch processing. • Test automation for an already existing system. • Test automation for an system built from scratch.
  26. 26. First case study • A system responsible for receiving buy and sell orders from international clients, processing those orders and sending them to brazilian stock exchange systems. • It’s a very critical system.
  27. 27. First case study International Clients WebLogic 8.1 WLI App Inbound Queue Oracle DB SQL Server MQSeries
  28. 28. First case study • Challenges • Run the system tests isolated. • Post messages into WebLogic JMS queues. • To determine when a process finishes.
  29. 29. Run the system isolated WebLogic 8.1 International Clients WLI App Inbound Queue MQSeries Oracle DB SQL Server
  30. 30. Fedora 4VM WindowsVM Run the system isolated WebLogic 8.1 WLI App Inbound Queue Oracle DB SQL Server MQSeries
  31. 31. Simplifying test setup • A web application was built to run inside the test server. • It acts as a “spy” on the server. • It can access the server database connections • It can access the server message queues.
  32. 32. Simplifying test setup WebLogic 8.1 WLI App Inbound Queue Fedora 4VM WindowsVM Oracle DB SQL Server MQSeries
  33. 33. Simplifying test setup WebLogic 8.1 WLI App Inbound Queue Fedora 4VM WindowsVM Oracle DB SQL Server MQSeries Test Spy
  34. 34. Simplifying test setup WebLogic 8.1 WLI App Test Spy Selenium Server Selenium RC Test cases Test environment
  35. 35. Simplifying test writing • A DSL has been made using Selenium to access the test application server. • The completion for each command is checked by issue SQL commands querying control tables until the results appear or a timeout occurs.
  36. 36. Simplifying test writing
  37. 37. Pros & Cons • The test execution is very “visual”. • Testers with basic programming skills wrote more than 400 test cases. • It doesn’t leave an open backdoor in the production environment. • It was very difficult to put in a continuous integration test environment.
  38. 38. Second case study • A system responsible for receiving allocation commands for contracts in future markets (BM&F). • It monitors the allocation status and displays alerts in a monitor. • System failures and delays can cause fines and image damages to the bank.
  39. 39. Second case study Allocation commands Tomcat 6 App Oracle DB Tables SP
  40. 40. Second case study • Challenges • Run the system tests isolated. • To control the execution of the stored procedure. • How to check in and out parameters for the stored procedure?
  41. 41. Run the system isolated Allocation commands Tomcat 6 App Oracle DB Tables SP
  42. 42. Ubuntu ServerVM Run the system isolated Tomcat 6 App Oracle DB Tables SP Remote Control
  43. 43. Ubuntu ServerVM SP control Tomcat 6 App Oracle DB Tables SP* Tables* Remote Control
  44. 44. Simplifying test setup Tomcat 6 App Remote Control Test Spy Test environment Spring Remoting Test cases
  45. 45. Simplifying test writing • A DSL has been made using Spring Remoting to access the test application server. • The completion for each command is checked by the remote control put inside the application.
  46. 46. Pros & Cons • It’s faster than Selenium solution. • The batch execution control is more precise. • Linux basedVM is more portable. • It demanded such effort to prepare the environment (VM, mock SP, semaphores)
  47. 47. Thank you! • Alberto Lemos (Dr. Spock) @drspockbr http://about.me/drspockbr • Danival T. Calegari @danivaltc danivaltc@gmail.com

×