Running Junit Cases with Jmeter(Basic)
Sampler for Jmeter. The sampler was introduced in 2.1.2 release of Jmeter. Earlier releases do not have the sampler.
Design
The current implementation supports standard Junit convention and extensions, like
oneTimeSetUp and oneTimeTearDown. Other features can be added on request. The
sampler works like the JavaSampler with some differences.
1. rather than use Jmeter's test interface, it scans the jar files for classes extending junit's
TestCase class. This means any class or subclass.
2. Junit test jar files are copied to jmeter/lib/junit instead of jmeter/lib
3. Junit sampler does not use name/value pairs for configuration. The sampler assumes
setUp and tearDown will configure the test correctly. Note: setUp and tearDown
methods must be declared public, so that Jmeter can use it.
4. The sampler measures the elapsed time only for the test method and does not include
setUp and tearDown.
5. Each time the test method is called, Jmeter will pass the result to the listeners.
6. 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.
7. The sampler reports unexpected exceptions as errors.
Functionality
Here is a description of the functionalty.
Name – name for the sample. This is the same as all jmeter samplers.
Package Filter – provides a way to filter the classes by package name.
Classname – the name of the class to test. The sampler will scan the jar files in
jmeter/lib/ext and jmeter/lib/junit for classes extending junit's TestCase.
Constructor String – a string to pass to the string constructor of the test class.
Test Method – the name of the method to test in the sampler.
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 be used with caution. If the selected method is oneTimeSetUp or oneTimeTearDown, this option should be checked.
Append assertion error – By default, the sampler will not append the assert failures to the failure message. To see the message in the result tree, check the option.
Append runtime exception – By default, the sampler will not append the exceptions to
the failure message. To see the stacktrace, check the option 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:
Empty Constructor:
public class myTestCase {
public myTestCase() {}
}
String Constructor:
public class myTestCase {
public myTestCase(String text) {
super(text);
}
Usage
Here is the step by step process
1.Write your junit test.
How to Write the Junit test cases using eclipse can be found in
Junit
Here i am putting the sample code for your reference.
This piece of code contains a class sampleTest and has 3 methods testsum(),testmulti() and testdiv()
import junit.framework.TestCase;
public class sampleTest extends TestCase
{
int a='a',b=5;
int c,d,e;
public void testsum()
{
c=a+b;
System.out.println("The Sum of two numbers is:" +c);
}
public void testmulti()
{
d=a*b;
System.out.println("The product of two numbers is:" +d);
}
public void testdiv()
{
e=a/b;
System.out.println("The division of two numbers is:" +e);
}
}2. jar the classes
In order to create jar file use the command
go to the directory your classes are stored in and type :-
"jar -cf myfile.jar *.class"
If your application or applet uses packages, then you'll need to do things a little differently. Suppose your classes were in the package mycode.games.CoolGame - you'd change to the directory above mycode and type the following :- (Remember to use / on UNIX systems)
jar -cf myfile.jar .\mycode\games\CoolGame\*.class
Now, if you have an existing JAR file, and want to extract it, you'd type the following
jar -xf myfile.jar
Working with JAR files isn't that difficult, especially if you've used the unix 'tar' command before. If you're planning on packaging an applet for Internet Explorer, or an application for Microsoft's jview, you might also want to consider .CAB files.
3.copy and paste the jar files into jmeter/lib/junit directory
4. start jmeter
5. select “test plan”
6. right click add -> thread group
7. select “thread group”
8. right click add -> sampler -> junit request
9. enter “my unit test” in the name
10. enter the package of your junit test
11.select the class you want to test
12.select a method to test
13.enter “test successful” in success message
14.enter “1000” in success code
15.enter “test failed” in failure message
16.enter “0001” in failure code
17.select the thread group
18.right click add -> listener ->view results tree
After successful run results can be seen in Jmeter console
One benefit of the Junit sampler is it allows the user to select any method from a variety of unit tests to create a test plan. This should reduce the amount of code an user needs to writeto create a variety of test scenarios. From a basic set of test methods, different sequencesand tests can be created using Jmeter's GUI.
Tip: In order to run all the methods in the class, Just add multiple Junit sampler with different class methods.
General Guidelines
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.
1. Write the setUp and tearDown methods so they are thread safe. This generally means
avoid using static memebers.
2. Make the test methods discrete units of work and not long sequences of actions. By
keeping the test method to a descrete operation, it makes it easier to combine test
methods to create new test plans.
3. 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.
4. If a test method is configurable, be careful about where the properties are stored. Reading
the properties from the Jar file is recommended.
5. Each sampler creates an instance of the test class, so write your test so the setup happens
in oneTimeSetUp and oneTimeTearDown.
6. If you select a class and no methods show up, it means the sampler had a problem
creating an instance of the test class. The best way to debug this is to add some
System.out to your class constructor and see what is happening.
Last Minuit tips
1.You should put the jars in the directory before starting jmeter
2.Make sure your unit tests conatins a constructor.
Comments
Post a Comment