JEvolve Getting Started Guide

Chapter 1. Introducing JEvolve

All useful software tend to evolve from one version to another. As part of testing and maintaining the software, it is quite useful to know how code has changed from an earlier version. JEvolve can analyze multiple versions of a program automatically and identify portions of the code that have changed. By relying on some interesting properties of the Java^TM language, it can even identify those methods that require to be (or do not require to be) retested. This can help a tester minimize regression testing effort.

The insight comes from the knowledge that Java program evolution can be analyzed in terms of atomic changes. An atomic change is the smallest meaningful unit of source change in a Java program. Some atomic changes do not cause behavior difference. For instance, changing the order of class members has no impact on behavior (we will assume, of course, that the code builds correctly). Hence, if this is the only atomic change in a program, then clearly there is no need to retest the class. More generally, if all changes to a class involve atomic changes that do not require retest, then the new version of the class need not be retested.

Consider, for example, that you have built an application in Java that is known to work correctly under JDK 1.2.1. Sometime later, a new version of the JDK, say version 1.2.2, is released. How will you find out if your application will work without any problems in the just released version of JDK? In the worst-case scenario, you will have to retest your application entirely under JDK 1.2.2 since you would not know (in fact, it is often painful to find out) what exactly has changed across the two versions of JDK. This retesting is likely to consume substantial effort when your application uses many JDK classes. Supposing you know that your code only uses JDK classes that have NOT changed across JDK 1.2.2, then you could completely eliminate regression testing. This is where JEvolve comes in: Given two versions of Java source, JEvolve can precisely identify what has changed across versions, and can even suggest its impact on retesting.

It is important to note that if part of a program is changed, it does not necessarily mean that the part must be retested (for example, renaming formal parameters of a method). Likewise, a method that has not undergone any change may have to be retested because it is affected by a change elsewhere (for instance, a significant change in a base class may require retesting derived classes).

Who can benefit from JEvolve?

JEvolve will be a great boon to developers, testers, and project leads.

Developers will find the tool quite useful in the process of merging multiple sources during code integration
Testers can easily determine the impact of code changes on regression testing
Project Leads will be able to track code changes across a product’s many versions

Salient Features

High performance analysis engine
Can handle large projects
Many reporting options
Built-in scripting support facilitates extensibility

System Requirements

Microsoft Windows^TM 95/98/NT/2000
Minimum 64 MB RAM, but more recommended for large projects
Minimum 10 MB Harddisk space, but more recommended
Other requirements as for any standard Windows application

Index Top Next