Testing Multiple Versions
Aus ExpeccoWiki
The Challenge
One of the biggest strengths of expecco is its dynamic adaptibility to changes in the system under test. For example, in a recent project we had to write test scenarios for regression tests of a web-GUI application which was about to be migrated to a newer version with slightly different test data and a slightly different GUI. (actually, due to the fact that the new version did not work as expected, we even had to switch back for a while, and suspend the switch for a few months).
The basic scenario of the test was as follows:
- Enter a test-data block into the applications service message queue (via an MQ-interface)
- using a web-GUI, start the message processing
- wait until the message is processed
- go to another web-GUI (on a different host) and check the message's fields
- fetch a transaction number there
- go to a third web-GUI, enter the transaction number and check some more fields there
- check (via an oracle interface) for integrity of a relational database
The Solution
On the highest level, the test is implemented as a simple straght sequence similar to:
Datei:MessageProcessing example1.png
when we had to make the switch for the new version, the message injection at the beginning was changed, to be controllable by a global flag:
Datei:MessageProcessing example2.png
This clag can either be initialized manually (after the suite is loaded), or passed in via a parameter-set from a file (--parameter command line option), or be passed-in from expeccoNET.
Datei:MessageProcessing example3.png
and also, some of the webGUI forms validations, using a control-flow split:
Datei:MessageProcessing example4.png
Notice, that if the messages were self-describing (which they were not, in this example), the setting of the controlling flag could even be done dynamically "on the fly":
Datei:MessageProcessing example5.png
Back to Online Documentation
