Adding step in load test to create/stage data for test


#1

Hi -

As part of our load test we would like to stage and create some data for our load tests to operate on. Similar to what you would do in a Junit @BeforeClass static method that would run once before running each individual test.

How can we model this with XLT?


#2

Hi!

XLT has no built-in mechanism to prepare something before the load test starts. Technically, it is possible to achieve what you want from within your test suite. You would need to perform your set-up steps in a static initializer block in one of your test case classes. However, in that initializer you also have to ensure that

  1. in a cluster of many load agent machines this set-up is run only once, and
  2. all other test cases on all other machines are blocked until the setup is done.

To achieve 1) you could use a check like “Session.getInstance().getAgentNumber() == 0” to decide if you can safely run the set-up steps in a certain agent JVM. Inside that JVM you could use any synchronization mechanism Java provides to further limit the execution to exactly one thread. The solution for 2) could be to either wait a certain time or query a global state in your test environment before leaving the static initializer.

Since this approach is not bullet-proof and a bit hacky, I would probably go for running the set-up before the load test. If you need to run the load test unattended, create a script that peforms both steps in a row:

prepare_data.sh || exit 1
mastercontroller.sh -auto -report

Best,
Joerg


#3

Thanks for the info.

One followup question -
Once data is created in the prepare data step, is there a way to then send an argument/some pointer to the data to all agents in the next step? I could potentially update some global state (like an external datastore) and have the second step lookup the global state but it would be much cleaner if I could send a pointer to all XLT agents from the first step.

Cheers,
Nihar


#4

Hi Nihar,

Your prepare data step could create new files with the respective info and store them to the XLT project folder to the config subdirectory. When the master controller is executed in the next step, these files will be uploaded together with the rest of the test suite to each agent machine. Your test cases can then read the files and access the info they need.

You might as well modify existing files, such as config/project.properties, for example by simply appending some properties.

Which way is prefered depends on the info you want to transport. If it is a list of IDs to use during the test, then separate data files would be the right choice. XLT comes with some helper classes to read data files, such as DataProvider and ExclusiveDataProvider.

If your info can be expressed using properties then I would go for appending these properties to an existing properties file. In your test cases you could use XltProperties.getInstance().getProperty(...) to access them.

Instead of appending properties to an existing file, you could also create a new properties file, for example info.properties in the config subdirectory, but in this case you need to include this file in project.properties or the test-run-specific properties file such as test.properties. For more info on including properties files, see the user manual.

Best,
Joerg