View RSS Feed


Understanding JMeter Element- JUnit Request Sampler

Rate this Entry
by , 06-21-2015 at 02:22 AM (2717 Views)
Understanding JMeter Element- JUnit Request Sampler

The current implementation supports standard Junit convention and extensions. It also includes extensions like oneTimeSetUp and oneTimeTearDown. The sampler works like the JavaSampler with some differences.

rather than use Jmeter's test interface, it scans the jar files for classes extending junit's TestCase class. That includes any class or subclass.
Junit test jar files should be placed in jmeter/lib/junit instead of /lib directory.
Junit sampler does not use name/value pairs for configuration like the JavaSampler. The sampler assumes setUp and tearDown will configure the test correctly.
The sampler measures the elapsed time only for the test method and does not include setUp and tearDown.
Each time the test method is called, Jmeter will pass the result to the listeners.
Support for oneTimeSetUp and oneTimeTearDown is done as a method. Since Jmeter is multi-threaded, we cannot call oneTimeSetUp/oneTimeTearDown the same way Maven does it.
The sampler reports unexpected exceptions as errors. There are some important differences between standard JUnit test runners and JMeter's implementation. Rather than make a new instance of the class for each test, JMeter creates 1 instance per sampler and reuses it. This can be changed with checkbox "Create a new instance per sample".

The current implementation of the sampler will try to create an instance using the string constructor first. If the test class does not declare a string constructor, the sampler will look for an empty constructor. Example below:
Junit Constructors
Empty Constructor:
public class myTestCase {
public myTestCase() {}

String Constructor:
public class myTestCase {
public myTestCase(String text) {

By default, Jmeter will provide some default values for the success/failure code and message. Users should define a set of unique success and failure codes and use them uniformly across all tests.


Name- Descriptive name for this element that is shown in the tree.
Search for JUnit4 annotations- Select this to search for JUnit 4 tests @test annotations)
Package filter- Comma separated list of packages to show. Example, org.apache.jmeter,junit.framework.
Class name- Fully qualified name of the JUnit test class.
Constructor string- String pass to the string constructor. If a string is set, the sampler will use the string constructor instead of the empty constructor.
Test method- The method to test.
Success message- A descriptive message indicating what success means.
Success code- An unique code indicating the test was successful.
Failure message- A descriptive message indicating what failure means.
Failure code- An unique code indicating the test failed.
Error message- A description for errors.
Error code- Some code for errors. Does not need to be unique.
Do not call setUp and tearDown- Set the sampler not to call setUp and tearDown. By default, setUp and tearDown should be called. Not calling those methods could affect the test and make it inaccurate. This option should only be used with calling oneTimeSetUp and oneTimeTearDown. If the selected method is oneTimeSetUp or oneTimeTearDown, this option should be checked.
Append assertion errors- Whether or not to append assertion errors to the response message.
Append runtime exceptions- Whether or not to append runtime exceptions to the response message. Only applies if "Append assertion errors" is not selected.

Create a new Instance per sample- Whether or not to create a new JUnit instance for each sample. Defaults to false, meaning JUnit TestCase is created one and reused.

The following JUnit4 annotations are recognised:
@test - used to find test methods and classes. The "expected" and "timeout" attributes are supported.
@Before - treated the same as setUp() in JUnit3
@After - treated the same as tearDown() in JUnit3
@BeforeClass, @AfterClass - treated as test methods so they can be run independently as required
Note that JMeter currently runs the test methods directly, rather than leaving it to JUnit. This is to allow the setUp/tearDown methods to be excluded from the sample time.

Disclaimer: The article/post is posted with the purpose of sharing knowledge and information.
The article may contain references, extract or content from other informative sources.
Researched/Authored/Compiled by -
Ronak Shah
Practice Head - Software Testing (QA), CIGNEX Datamatics

vBulletin Optimisation provided by vB Optimise v2.6.0 Beta 4 (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
User Alert System provided by Advanced User Tagging v3.0.9 (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
Questions / Answers Form provided by vBAnswers (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
vBNominatevBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
Username Changing provided by Username Change (Free) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
BetaSoft Inc.
Digital Point modules: Sphinx-based search
All times are GMT -8. The time now is 11:08 PM.

Copyright BetaSoft Inc.