---
title: "JUnit Request"
description: "Configure the JMeter JUnit Request samplers: properties, defaults, and practical usage notes for building reliable load tests."
url: https://docs.jmeter.ai/components/junit-request/
lastUpdated: 2026-10-01
source: docs.jmeter.ai
---

# JUnit Request

*Part of the **Samplers** category. Also documented in context in the [full Component Reference](/user-manual/component-reference/#junit-request).*

![JUnit Request](/images/screenshots/junit_sampler.png)

The current implementation supports standard JUnit convention and extensions. It also
includes extensions like `oneTimeSetUp` and `oneTimeTearDown`. The sampler works like the
[Java Request](/components/java-request/) 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. You can also use the “`user.classpath`” property to specify where to look for `TestCase` classes.
- JUnit sampler does not use name/value pairs for configuration like the [Java Request](/components/java-request/). 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:

```java
public class myTestCase {
  public myTestCase() {}
}
```

String Constructor:

```java
public class myTestCase {
  public myTestCase(String text) {
    super(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.

> **Note**
> #### General Guidelines
>
> If you use `setUp` and `tearDown`, make sure the methods are declared public. If you do not, the test may not run properly.
>
> Here are some general guidelines for writing JUnit tests so they work well with JMeter. Since JMeter runs multi-threaded, it is important to keep certain things in mind.
>
> - Write the `setUp` and `tearDown` methods so they are thread safe. This generally means avoid using static members.
> - Make the test methods discrete units of work and not long sequences of actions. By keeping the test method to a discrete operation, it makes it easier to combine test methods to create new test plans.
> - Avoid making test methods depend on each other. Since JMeter allows arbitrary sequencing of test methods, the runtime behavior is different than the default JUnit behavior.
> - If a test method is configurable, be careful about where the properties are stored. Reading the properties from the Jar file is recommended.
> - Each sampler creates an instance of the test class, so write your test so the setup happens in `oneTimeSetUp` and `oneTimeTearDown`.

| Name | Required | Description |
| --- | --- | --- |
| Name | No | Descriptive name for this element that is shown in the tree. |
| Search for JUnit4 annotations | Yes | Select this to search for JUnit4 tests (`@Test` annotations) |
| Package filter | No | Comma separated list of packages to show. Example, `org.apache.jmeter`,`junit.framework`. |
| Class name | Yes | Fully qualified name of the JUnit test class. |
| Constructor string | No | 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 | Yes | The method to test. |
| Success message | No | A descriptive message indicating what success means. |
| Success code | No | An unique code indicating the test was successful. |
| Failure message | No | A descriptive message indicating what failure means. |
| Failure code | No | An unique code indicating the test failed. |
| Error message | No | A description for errors. |
| Error code | No | Some code for errors. Does not need to be unique. |
| Do not call setUp and tearDown | Yes | 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 | Yes | Whether or not to append assertion errors to the response message. |
| Append runtime exceptions | Yes | 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 | Yes | 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**
> 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.
> As a consequence, the sampler time excludes the time taken to call `setUp`/`tearDown` methods and their annotation based alternatives.

## Related

- [API Load Testing Guide](/topics/api-load-testing/)
- [cURL & HAR to JMX Converter](/tools/curl-to-jmx/)
- [Full Component Reference](/user-manual/component-reference/)
- [Functions and Variables](/user-manual/functions/)