Pursue code Quality

In the development of applications, validating the performance of applications is almost always a secondary status. Note that my emphasis is on verifying the performance of the application. Application performance is always a primary consideration, but the development cycle rarely includes validation of performance.

For a variety of reasons, performance testing is often delayed until later in the development cycle. In my experience, companies do not include performance testing in the development process because they don't know what to expect for the application being developed. Some (performance) indices are presented, but these indices are based on the expected load.

Performance testing becomes a top priority when one of the following two situations occurs:

There are obvious performance problems in production.

Before agreeing to pay, the customer or prospect asks questions about the performance index.

This month, I'll introduce two simple performance test techniques that will be tested before any of these two scenarios occur.

To test with JUnitPerf

In the early stages of software development, it was easy to determine the basic low-end performance index using JUnit. The JUNITPERF framework can quickly translate tests into simple load tests and even stress tests.

You can use JUnitPerf to create two types of tests: Timedtest and LoadTest. Both of these types are based on decorator design patterns and take advantage of the JUnit suite mechanism. Timedtest creates a (time) limit for the test sample--If this time is exceeded, the test fails. LoadTest runs with timers, and it creates a human load on a specific test case by running the number of times it takes (the time interval is controlled by the configured timer).

Appropriate time limit test

JUnitPerf Timedtest allows you to write tests with relevant time limits--if that limit is exceeded, the test is considered a failure (even if the test logic itself is actually successful). Time-Limit testing is helpful in determining and monitoring performance indices compared to other tests when testing methods that are important for business. Even more carefully, you can test a series of methods to ensure that they meet a specific time limit.

For example, suppose there is a Widget application in which a particular approach to business-critical (such as Createwidget ()) is a strict performance-limiting test target. Suppose you need to perform a performance test on the functional aspects of executing the Create () method. This is usually determined by different teams using different tools at the end of the development cycle, which often does not point to precise methods. But suppose you decide to choose an early-test method instead.

To create a timedtest first, you create a standard JUnit test. In other words, you will extend the TestCase or its derived classes and write a method that starts with test, as shown in Listing 1:

Listing 1. Simple widget Test

public　class　WidgetDAOImplTest 　extends　TestCase　{
　 private　WidgetDAO　dao;

　 public　void　testCreate()　throws　Exception{
　 IWidget　wdgt　=　new　Widget();
　 wdgt.setWidgetId(1000);
　 wdgt.setPartNumber("12-34-BBD");
　 try{
　　 this.dao.createWidget(wdgt);
　 }catch(CreateException　e){
　　 TestCase.fail("CreateException　thrown　creating　a　 Widget");
　 }
　 }

　 protected　void　setUp()　throws　Exception　{
　 ApplicationContext　context　=
　　 new　ClassPathXmlApplicationContext("spring-config.xml");
　 this.dao　=　(WidgetDAO)　context.getBean("widgetDAO");
　 }
}