Plenty of software could use more complete testing before being released to production. Unfortunately, it’s not always feasible to test an application as thoroughly as industry best practices suggest. Whether you have a QA staff that tests your software or you partially test your applications within your own development team, project timelines often determine the degree to which testing can be completed.
One product on the market claims to make software and component testing less time-consuming with its automated white box, black box, regression, and standards tests. Jtest version 4.1, released by ParaSoft, costs $3,495 per seat and runs on Windows NT/2000, Windows 95/98, Linux, and Solaris. Recommended Windows system requirements are Windows 2000/NT with a Pentium compatible 300 MHz or higher (400 recommended) and 128 MB of RAM.
Jtest handles the following:
- White box—This is used for testing code construction. During white box testing, Jtest tests code at the class level to make sure that unexpected input doesn’t cause a system crash. Jtest can perform white box testing on any Java class or component, including those that reference external resources.
- Black box—This is used for testing code functionality. In black box testing, Jtest checks that a class behaves according to specification.
- Regression—This is used for testing modified code using inputs and test parameters from prior tests. This maintains code integrity. With Jtest, you can perform regression testing at the class level, and it's pretty easy to complete by clicking on the tests you’ve already created.
- Static analysis—This is used for standards testing of your code against industry best and customizable standards.
We recently took Jtest for a test drive on a Pentium 350 MHz with 196 MB of RAM. We discovered that overall, using Jtest is pretty straightforward. The software installs easily, sufficient documentation is available on ParaSoft’s Web site, and the tech support staff was very eager and capable in helping to install the product.
The user interface is easy to understand. To start testing a class, simply browse and navigate to your Java class file. If the Java source file isn’t on the same directory, Jtest will ask you to locate it. Click Start, and Jtest automatically performs the tests.
After the testing completes, Jtest displays errors in a user-friendly tree navigation window. When a coding standard rule is violated, you can double-click on the error message to navigate to the offending line of code or right-click on the error line and view or edit source, read the rule description, or suppress the error message.
The metrics section is simple to use and is a great tool for measuring programmer productivity and code quality. You can select what you want to track, how much code has been produced, how many methods are in a class, and the number of fields. The metrics page provides all this information. You can also track project metrics over time.
When it tests your code, Jtest checks a comprehensive list of more than 200 rules and best practice Java coding standards. For instance, it verifies that the number of @params in the Javadoc commenting of a method equals the number of parameters for that method and makes sure that a method doesn't exceed the maximum statement counts.
Take a little time to customize this section, and you can greatly augment your team’s ability to enforce coding standards. The customization feature is easy to figure out, and you will probably want to use it to control which errors get reported. For example, after we ran our first test, Jtest reported that concatenating strings doesn’t work in internationalization. While this is true, concatenation is a common practice, and we didn't need it reported as an error. On the other hand, Jtest reported that our code called a synchronized method in a loop. I’m glad I found that because synchronized calls can be very expensive in terms of performance.
Perhaps Jtest offers the most value to programmers in its Design by Contract (DbC) features. You essentially write boundary condition test cases in the Javadoc commenting of your class methods. Jtest will automatically read and perform these test cases. Without DbC, most code we tested would require additional manual work to build the test cases.
ParaSoft offers a companion package called Jcontract, which graphically displays and tests DbC cases. The contracts specify preconditions, postconditions, and assertions that a method must meet throughout its execution. For our testing, we did not implement Jcontract.
Jtest simplifies all work related to testing Java classes. Writing and executing unit tests in Jtest is quick and easy. Once you have prepared your test cases in Jtest, save them. When you need to perform regression testing, all you have to do is rerun your tests. Pretty cool.
Jtest gets high marks. It installs quickly, performs well, and is very user friendly. It would be useful if every Java developer could have a copy on his or her desktop, but the price might prohibit that. If your development team is like the ones we know—which run, among other expensive products, a Java IDE and a modeling tool—the additional cost for a copy of Jtest per developer is a little out of reach. Even so, you might be able to designate a couple of developers to run the tests for the others.
Have you used Jtest?
Do you have experience using Jtest or other Java testing tools? What do you think of them? Send us an e-mail with your thoughts and experiences or post a comment below.