Parasoft continues to send its Jtest Java testing suite out to hunt down bad Java code. And Jtest knows that the definition
of bad Java code continues to expand: One bit of code might be bad because its developer didn’t follow best practices for
coding style, making it difficult for other programmers to understand and interface with it. Yet another bit might be bad
because it is poorly factored and overly complex, or because it crashes when executed. A different bit of code might be bad
because it was written with no consideration for security and could be easily compromised by a malicious hacker.
Parasoft Jtest 8
Parasoft, parasoft.com
|
 Excellent 9.0 |
|
| criteria |
score |
weight |
| Documentation |
9 |
20% |
 |
| Interoperability |
10 |
20% |
|
| Performance |
9 |
20% |
|
| Scalability |
9 |
20% |
|
| Setup |
8 |
10% |
|
| Value |
8 |
10% |
|
|
|
Cost:
$50,000 for server, support for five licenses
Platforms:
OS: Windows, Linux, Solaris; IDE: Stand-alone, Eclipse (3.0 or later), IBM Rational Application Developer, IntelliJ
Bottom Line:
Jtest was already a great Java testing tool; now it’s even better. Version 8 adds more pre-loaded rules and the new BugDetective
analysis module for locating problems and identifying their origin. It takes on everything from unit tests to functional tests,
and it does not limit your testing of any particular Java component.
|
|
About our Reviews and Scoring Methodology
|
|
|
|
I’ve reviewed two previous editions of Jtest — Jtest 7.0 and Jtest 5.0 — but in Version 8, Jtest updates and extends several existing features. For example, Jtest 7.0’s static-analysis engine
came pre-loaded with 500 rules that allowed it to locate problems and coding violations by examining an application’s source.
The static-analysis component in Jtest 8 is equipped with more than 700 such rules.
New rules cover areas such as Java 5 specifics and Hibernate, and you can still define your own rules, although I found that
process a bit complicated on account of the elaborate syntax Jtest employs. On the one hand, the language used to define rules
allows you to cover a wide range of contingencies; on the other hand, the richness of the language creates a steep learning
curve.
Jtest’s static-analysis machinery has also been modified, turning it into a kind of static/dynamic hybrid. Specifically, the
new BugDetective module examines source and class files (without executing them, mind you), explores execution paths, and
uncovers potential bugs that would otherwise appear only after lengthy run-time testing.
BugDetective’s execution explorations are not limited to a method, a class, or even a package; they can cross all logical
boundaries. In addition, when it finds a problem, it not only locates where the problem is likely to manifest itself, but
it also identifies the problem’s origins so that you can tell where the “bad data” got into the system.
BugDetective will locate potential null-pointer exceptions, resource leaks (such as neglecting to close an opened socket),
and a variety of security issues. In this last case, most of BugDetective’s security rules locate code vulnerable to injection
attacks: code that uses “uncleansed” user input to create a resource path string, or a query string.
Jtest 7’s Test Case Sniffer technology returns in Jtest 8 under a new name, “Tracer.” Tracer hooks into an application and
gathers information about its execution. From that information, Tracer then creates a host of tests to launched against the
application.
Most of the tests created are based on a JUnit foundation, but Jtest adds support for Cactus, a JUnit-extending framework from the Jakarta Project that recognizes just about every server-side component there is; HttpUnit, a general-purpose Web-testing framework that mimics a user executing from a browser; Springs; Struts; and other platforms.
Other improvements cover the entire Jtest tool collection. For example, past versions of Jtest generated tests at the class
level. Now you can set filters on test creation so that tests are generated for, say, only public methods, ignoring private
and protected methods.
Such “fine-tuning” of tests goes even further if Jtest is connected to a version control system. In that case, you can do
things such as specify that Jtest create tests for only source code modified since a given date and restrict test generation
to new code.
Bug Detective is perhaps Jtest 8’s best addition. It can — if you have the time — be configured to exhaustively explore an
application’s execution paths. The default “exploration depth” is set to about 100 sequentially executed lines, but that can
be adjusted to something much larger. And in this age of copious available processor cycles, it wouldn’t be unthinkable to
devote a small farm of test systems to simply sit around all night, exploring your Java source, and maybe finding something
you wouldn’t have expected. That’s where Jtest shines brightest.
E-mail
Printer Friendly
Reprints
(InfoWorld) - In the litigious world we live in, deploying a unified communications platform in your enterprise could...
