Slides used at the JavaOne 2011 session.

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. Agenda
• Principles & Proposals
• Why to use a DSL to test?
• 2 Case Studies

3. Objective
“Show a simple way to improve
batch process tests
with a Domain-Specific Language”

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. Agenda
• Principles & Proposals
• Why to use a DSL to test?
• 2 Case Studies

6. Principles for a good
Test Automation
• Automated tests must be:
• Easy to write
• Easy to run
• Self-contained
• Run quickly
• Always updated

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. 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. Agenda
• Principles & Proposals
• Why to use a DSL to
test?
• 2 Case Studies

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. 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. 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. External DSL
• It has less technological
limitations
• It adds more value
per line of code
• It can be used by a
layman

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. Steps for DSL Setup

16. Steps for DSL Setup
• How can I run a batch in an isolated form?

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. 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. Steps for DSL Setup

20. Steps for DSL Setup
• Use the builder pattern

21. Steps for DSL Setup
• Use the builder pattern
• Provide default values or they will be automatically
generated

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

25. Agenda
• Principles & Proposals
• Why to use a DSL to test?
• 2 Case Studies

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

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

28. First case study
International Clients
WebLogic 8.1
WLI
App
Inbound
Queue
Oracle DB
SQL Server
MQSeries

29. First case study
• Challenges
• Run the system tests isolated.
• Post messages into WebLogic JMS
queues.
• To determine when a process finishes.

30. Run the system isolated
WebLogic 8.1
International Clients
WLI
App
Inbound
Queue
MQSeries
Oracle DB
SQL Server

31. Fedora 4VM
WindowsVM
Run the system isolated
WebLogic 8.1
WLI
App
Inbound
Queue
Oracle DB
SQL Server
MQSeries

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

33. Simplifying test setup
WebLogic 8.1
WLI
App
Inbound
Queue
Fedora 4VM
WindowsVM
Oracle DB
SQL Server
MQSeries

34. Simplifying test setup
WebLogic 8.1
WLI
App
Inbound
Queue
Fedora 4VM
WindowsVM
Oracle DB
SQL Server
MQSeries
Test Spy

35. Simplifying test setup
WebLogic 8.1
WLI
App
Test Spy
Selenium
Server
Selenium
RC
Test
cases
Test environment

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

37. Simplifying test writing

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

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

40. Second case study
Allocation commands
Tomcat 6
App
Oracle DB
Tables SP

41. 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?

42. Run the system isolated
Allocation commands
Tomcat 6
App
Oracle DB
Tables SP

43. Ubuntu ServerVM
Run the system isolated
Tomcat 6
App
Oracle DB
Tables SP
Remote
Control

44. Ubuntu ServerVM
SP control
Tomcat 6
App
Oracle DB
Tables SP*
Tables*
Remote
Control

45. Simplifying test setup
Tomcat 6
App
Remote
Control
Test Spy
Test environment
Spring
Remoting
Test
cases

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

47. 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)

48. Thank you!
• Alberto Lemos (Dr. Spock)
@drspockbr
http://about.me/drspockbr
• Danival T. Calegari
@danivaltc
danivaltc@gmail.com