Bug 50034 - Provide API for running JMeter
Summary: Provide API for running JMeter
Status: NEW
Alias: None
Product: JMeter
Classification: Unclassified
Component: Main (show other bugs)
Version: 2.5
Hardware: All All
: P1 enhancement with 6 votes (vote)
Target Milestone: ---
Assignee: JMeter issues mailing list
: 50537 64968 (view as bug list)
Depends on:
Reported: 2010-10-01 05:56 UTC by BTO Team @ Sabre-Holdings
Modified: 2020-12-21 19:24 UTC (History)
8 users (show)


Note You need to log in before you can comment on or make changes to this bug.
Description BTO Team @ Sabre-Holdings 2010-10-01 05:56:54 UTC
To enable effective test automation with Jmeter we would like to use Jmeter in non-gui mode calling it directly in Java app. This is very similar scenario as in case maven-jmeter-plugin...

Currently we have to:
1. create new JMeter() 
2. invoke start with command line args.
3. parse JMeter log to find the results.
4. change security manager to capture System.exit calls
5. wait for all of the threads that it spawned to exit

We would like to:
1. create new JMeterNonGUI()
2. invoke runTest with all arguments passed as appropriate objects (no need to wrap and parse them)
3. wait for runTest to end (it should execute all tests)
4. read test results returned by runTest


JMeterNonGUI jmeter = new JMeterNonGUI();
TestResults results = jmeter.runTests(jmxTestFile);

I propose to:
- extract from JMeter class JMeterGUI class responsible for starting GUI version of JMeter
- extract from JMeter class JMeterNonGUI class responsible for starting non-GUI version of JMeter
- refactor the code so that JMeter class will be responsible only for parsing command line arguments and delegating JMeter start to appropriate class JMeterGUI or JMeterNonGUI
- create public JMeterNonGUI.runTests method that will block execution until test end and will gather test results to some TestResults list (the hardest part?)
- replace all System.exit calls with call to some SystemExitHandlerInterface that in case of non-GUI method can be implemented without using System.exit
Comment 1 Sebb 2011-01-03 07:37:58 UTC
*** Bug 50537 has been marked as a duplicate of this bug. ***
Comment 2 palgemeen 2011-07-25 11:43:04 UTC
Thanks to the BTO Team @ Sabre-Holdings for logging this feature request. I would also benefit from such API, as I think anyone wanting to run JMeter scripts as part of a larger automated test effort. Especially when being used to automated dependency management like with Maven it is a bit of a set-back to have the administrative overhead of installing JMeter at a fixed path on the machines of all developers and build servers.
Also if you want to use e.g. FitNesse for maintaining test and reporting on results, then you find that it is a pain to write reliable fixtures for this.

Dear developers, please consider working in this. It would be much appreciated.

For reference: before I found this issue I started a thread on the mailing list: http://mail-archives.apache.org/mod_mbox/jakarta-jmeter-user/201107.mbox/%3C38FD45F8B3DE904BBF437A2E16B81EC806CF47A00B@DEEXVS51.wincor-nixdorf.com%3E
Comment 3 Sebb 2011-07-25 12:37:07 UTC
Returning the TestResults at the end of the run could require a lot of memory.

A better solution might be to provide a call-back mechanism which returns each sample as it occurs.
Comment 4 Martin Šimek 2012-05-09 07:01:39 UTC
Currently we are running JMeter as a new process which is quite lame when running from java. For our purposes it would be enough to be able to run main() and be sure that all threads finish before the method finishes. Results would be also fine, but currently we just load resulting XML file using dom4j.

However, the library behavior would be the most clear solution.
Comment 5 Dzmitry Kashlach 2014-07-18 11:57:42 UTC
AFAIK. it's possible now to run JMeter from external application using NewDriver class, isn't it?
Comment 6 Philippe Mouawad 2019-02-21 16:54:48 UTC
We could create a Helper class to build HTTP Test plans in an easier way.
It could be used internally also.
Comment 7 Philippe Mouawad 2020-12-18 23:36:03 UTC
*** Bug 64968 has been marked as a duplicate of this bug. ***