Shulou(Shulou.com)06/02 Report--

This article shows you how to use the open source performance testing framework p-unit, which is concise and easy to understand. It will definitely brighten your eyes. I hope you can get something through the detailed introduction of this article.

Recognize p-unit: an open source performance testing framework p-unit is an open source performance testing framework, unlike JUnit, JUnit is concerned with the correctness of test cases, while p-unit is not only concerned with the correctness of test cases, but also collects performance parameters of test cases. By default, p-unit collects the time and memory consumption of test cases and can generate files, pictures, and reports in PDF format. In addition, p-unit supports parametric testing, multithreaded testing, and performance comparison between different Java virtual machines.

Introduction to p-unit

Maybe we're used to using JUnit to write unit tests to ensure code quality (as I've been doing all the time), but we often run into this problem:

What is the correctness of the program under multithreading?

How to test the performance of a program?

When there are multiple options to choose from, how do you technically compare the performance of different schemes?

For question 1, may we be resigned to fate? Is it based on manual analysis or user feedback? The unit test coverage of many software under single thread is quite high, which ensures the robustness of the code. However, multithreaded testing is often ignored, which does not mean that multithreaded testing is not important. On the contrary, correcting a user's reported multithreaded BUG is often much higher than that of a single thread, because test cases are often not 100% reproducible. This requires programmers to pay full attention to it in the development stage. At present, one of the important reasons for the lack of multithreaded unit testing is that there is no easy-to-use testing tool like JUnit, and rewriting test cases is often not accepted by programmers.

For question 2, a mature product that cares about performance often has a performance testing platform. This test platform should focus on testing the business logic itself, without worrying about how to run the test case. Have you ever had a hard time writing such a test platform? And spend time producing intuitive reports?

For question 3, we often write a prototype to compare the performance of different products. How do we compare execution speed and memory consumption? Or choose the virtual machine that works best for you?

P-unit is such an open source performance testing software that can help you solve the above problems. P-unit can:

Multithreaded support: the same test case can be executed in a single thread or multithreaded, and the test case developer only needs to write a set of test cases.

Parameterized test cases: many test cases require testing the performance of the same function at different orders of magnitude.

Performance testing of different virtual machines: you only need to specify the path of the virtual machine to test the performance of the same test case on different virtual machines, and the performance differences can be directly displayed on the report.

Event mechanism architecture: punit is based on the event mechanism framework, if users want to customize the report, just implement the event responder and register the responder to the punit core.

Multithreaded execution test case

Before we look at how to execute test cases with multiple threads, let's take a look at how to execute test cases using p-unit single thread. Unlike JUnit, p-unit test cases do not need to inherit any test classes or implementation interfaces to execute the methods started by test. Although the Annotation feature is added to JUnit 4, the test method prefix "test" is still the first choice for testers. So if your JUnit test case follows the test naming convention, then p-uni t is compatible with running JUnit test cases.

Listing 1 below is the most common test case:

Public class SimpleTestClass {public void setUp () {SampleUtil.doSomething ();} public void tearDown () {SampleUtil.doSomething ();} public void testA () {System.out.println ("testA"); SampleUtil.doSomething ();} public void testB () {SampleUtil.doSomething ();} public void testC () {SampleUtil.doSomething ();}} public class SampleUtil {private static Random _ random = new Random (); public static void consumeMemory (int length) {byte [] data = new byte [length] For (int I = 0, j = 0; I < data.length; + + I) {+ + j;}} public static void consumeTime (int time) {ThreadUtil.sleepIgnoreInterruption (time);} public static void doSomething () {consumeTime (Math.abs (_ random.nextInt ())% 100000); consumeMemory (Math.abs (_ random.nextInt ())% 100000);}}

This is a common test case, but note that this is only a test case and does not contain any other logic, which is also an idea that p-unit pursues to separate the business logic from the test run environment. For the same test case, users can choose different test environments to run, rather than being bound to a specific test software tool. Now let's see how p-unit runs this test case. You just need to write a line of code in the main function to run it:

Listing 2. Run the test case with a single thread

CODE:

Public static void main (String [] args) {

New PUnitSoloRunner () run (SimpleTestClass.class)

} listing 3. Single-thread run test case results

[solo] Started running samples.SimpleTestClass

Samples.SimpleTestClass

TestA

TestA ()-[287.0ms]

TestB ()-[27.0ms]

TestC ()-[213.0ms]

Total: 3, failures:0 (GREEN)-2025.0ms

Is it the same as expected? Let's take a look at how to execute this test case with multiple threads. As you may have guessed from the above example, the main function still needs only one sentence of code, just replace PUnitSoloRunner with PUnitConcurrentRunner!

Listing 4. Run test cases with multi-thread

Public static void main (String [] args) {new PUnitConcurrentRunner () .run (SimpleTestClass.class);}

Listing 5. Multithreaded test case results

[concurrent] Started running samples.SimpleTestClasssamples.SimpleTestClasstestAtestAtestAtestAtestAtestAtestAtestAtestAtestAtestA ()-[405.0ms] testB ()-[469.0ms] testC ()-[503.0ms] total: 3, failures:0 (GREEN)-1447.0ms

Is it the same as expected? By default, p-unit starts 10 threads to execute. To specify a different number of threads, simply pass the number of threads as a parameter to PUnitConcurrentRunner. P-unit even supports different number of threads for different test cases, which requires the test case to implement the Concurrent interface defined in p-unit, which is defined as:

Listing 6. P-unit Concurrent interface

CODE:

Public interface Concurrent {

Public int concurrentCount ()

} the meaning of this interface, I believe there is no need to explain, return the number of threads required for the test case.

Latest reply

Quake at 2007-11-21 15:35:48

Parameterized test case

Performance testing, different from unit testing, often requires testing the performance of different orders of magnitude in the same test scenario. JUnit is a very excellent unit testing tool, but it does not cover this aspect. For example, if we compare the method bar () of the class library Foo1 and the method bar () of the class library Foo2, which is more suitable for our application, we need to test the performance of this function in the range of possible orders of magnitude of the application. Experienced developers know that they often encounter better situations in small scale An and large order B, so comprehensive testing is very important for code performance understanding and can help developers make the right decision. P-unit supports passing parameters to the test method. The test case needs to implement the parameterizable interface of p-unit. The main method of this interface is to return a list of parameters, which will be passed to the test method one by one.

Listing 7. P-unit parameterized test case

Public class ParamTestClass implements Parameterizable {public static void main (String [] args) {new PUnitSoloRunner (). Run (ParamTestClass.class);} public Parameter [] parameters () {return new Parameter [] {new ParameterImpl (10), new ParameterImpl (20)};} public void testA (ParameterImpl param) {SampleUtil.doSomething ();} public void testB (ParameterImpl param) {SampleUtil.doSomething ();} public void testC (ParameterImpl param) {SampleUtil.doSomething () } public void setUpAfterWatchers (Parameter param) throws Exception {} public void setUpBeforeWatchers (Parameter param) throws Exception {} public void tearDownAfterWatchers (Parameter param) throws Exception {} public void tearDownBeforeWatchers (Parameter param) throws Exception {} static class ParameterImpl implements Parameter {private int _ count;ParameterImpl (int count) {_ count = count;} public int count () {return _ count;} public String toString () {return String.valueOf (_ count);}

The execution result of the above code is:

CODE:

[solo] Started running samples.ParamTestClass

Samples.ParamTestClass

TestA (10)-[57936.0bytespr 447.0ms]

TestA (20)-[33128.0 bytespr 61.0ms]

TestB (10)-[24832.0bytespen 137.0ms]

TestB (20)-[0.0bytesminute 63.0ms]

TestC (10)-[83560.0bytes 468.0ms]

TestC (20)-[16528.0 bytes per 47.0ms]

Total: 6, failures:0 (GREEN) 1450.0ms

As you can see from the above results, each method is executed twice, each time passing in different parameters. Run parameterized test programs with multiple threads? I believe the reader already knows how to implement it, just replace PUnitSoloRunner with PUnitConcurrentRunner.

Quake at 2007-11-21 15:40:22

Run the environment test case

With the open source of Java, there are more Java runtime environments. In addition to the reference implementation of SUN, BEA and IBM all have their own Java runtime environment, which is more like Apache Harmony's open source runtime environment (although Apache Harmony can not be called Java runtime environment yet). Running environment test cases can provide some help for running environment developers and choosing running environment. For example, the following example is to test the performance of java.util.ArrayList and java.util.Vector in two different running environments. The test case is written in exactly the same way as a normal test case. We just need to tell p-unit the Java path of the different running environment and the correct classpath, and then call the runVMs function:

Listing 9. P-unit run environment test case

Public static void main (String [] args) {PUnitSoloRunner runner = new PUnitSoloRunner (); runner.addPUnitEventListener (new OverviewReporter (new ImageRender (); runner.runVMs (ListTestClass.class, new VM [] {VMConfig.HARMONY, VMConfig.SUN});} public class VMConfig {private static String CLASSPATH = "- cp correct_classpath_including_all_jars_and_path"; private static String HARMONY_PATH = "harmony_pathbinjava" + CLASSPATH; private static String SUN_PATH = "sun_pathbinjava" + CLASSPATH Public static VM HARMONY = new VM (HARMONY_PATH, "HARMONY"); public static VM SUN = new VM (SUN_PATH, "SUN");} public class ListTestClass {private static final int LIST_COUNT = 1000000 politics private static Object element = new Object (); private Random indexGenerator = new Random (); public void testInsertArrayList () {ArrayList arrayList = new ArrayList (LIST_COUNT); insertSequence (arrayList); insertRandom (arrayList);} public void testInsertVector () {Vector vector = new Vector (LIST_COUNT); insertSequence (vector); insertRandom (vector) } public void insertSequence (List list) {for (int I = 0; I < LIST_COUNT; + + I) {list.add (element);}} public void insertRandom (List list) {for (int I = 0; I < LIST_COUNT; + + I) {list.add (indexGenerator .nextInt (LIST_COUNT), element);}

The version of HARMONY used by the author is faster in this test case, but consumes more memory.

From the example above, we have seen two forms of p-unit output, the console and the report picture. By default, p-unit is output to the console. P-unit uses an event mechanism that provides notification events at each node of the runner. All the output is achieved by registering the event responder. This also shows that the result output is completely isolated from the runner, and users can customize their own reports. P-unit has four built-in outputs, namely, console, file, picture report, and PDF report. We have seen the picture report in the example in the previous section, and the code is:

Listing 10. Add p-unit overall Picture report

CODE:

Runner.addPUnitEventListener (new OverviewReporter (new ImageRender (); p-unit built-in reports have three different granularities: overall level (OverviewReporter), TestSutie level (TestSuiteReporter), and test case class level (TestClassReporter). All three levels can output in either picture format or PDF format, so there are a total of six types of output. The above code is to output the picture at the overall level. Because event listeners are independent of each other, you can choose to output both pictures and PDF files by adding event listeners:

Listing 11. Add multiple p-unit event listeners

Runner.addPUnitEventListener (new OverviewReporter (new ImageRender (); runner.addPUnitEventListener (new OverviewReporter (new PDFRender ()

The above is how to use the open source performance testing framework p-unit. Have you learned any knowledge or skills? If you want to learn more skills or enrich your knowledge reserve, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.