A software tool and methods for preventing software modifications from invalidating previously passed integration test cases is provided. The software tool and methods automatically modify an integrated software subroutine to collect test data for selected units of the integrated software. The software tool and methods also generate a software test environment including a driver and one or more stubs for each selected software unit. Subsequent versions of the software unit are then stimulated by the driver and stubs using the collected test data. The responses from the new version of the software unit are compared to the responses collected from the old version. Differences between the responses of the two software version are flagged, thereby preventing software modifications on the software unit from invalidating previously passed tests. Furthermore, the software tool and methods automate the incremental integration and testing of software units whose modifications are related. The software tool and methods automatically determines the set of software units to be combined, the set of test cases to exercise and the test results that must be satisfied so that previously passed integration tests will not fail. Several methods of reducing the potentially unbounded test data to a manageable amount are also described. The test data may be used to analyze important properties of the software. The test data and test environment are useful in several different phases of software development.

A preferred embodiment provides a system, method, and computer program product for software code testing. When a code change causes a regression, the system tests each modification to determine and isolate the cause of the regression.

In a method for testing computer code, each branch that occurs within the machine-readable code is located. A first tracepoint is placed immediately after the beginning of the branch and a second tracepoint at the target address of each branch, each tracepoint generating an indicator. When the machine-readable code with the tracepoints is executed on the target computer, the method identifies those indicators that have been generated by their corresponding tracepoints, thereby permitting determination of those branches that the program control flow has not passed through. The test cases are modified to exercise the previously omitted branches, and the converted code is re-executed, until all branches have been properly exercised. The tracepoints are automatically eliminated after they have performed their intended function.

Memory management routines for a program are instrumented to check if the address of an object they are handling is equal to the value of a predetermined pointer. If the address of the object equals the value of the global pointer, then a debugging routine is called. In a debugger, a breakpoint is placed on the debugging routine, and the program is run until the breakpoint is tripped. At this or one of the later breakpoints, the corrupted memory address is repeatedly inspected until the operation that caused the corruption is executed.

Object-code instruction traces are employed to analyze selected instructions of an application program for possible failure when confronted by a year-2000 date. The analysis includes directly identifying one or more instructions of the application program that may fail, as well as identifying whether the one or more instructions have a characteristic of a predefined false-positive failure pattern. A failure-pattern descriptor is assigned to each examined instruction which is indicative of whether the instruction may fail when confronted by a date in the year-2000 range, and whether the instruction is a possible false-positive failing instruction. The analysis employs user-specifiable run-control values, as well as predetermined filter-specification values in comparing traces of each selected object-code instruction to predefined instruction failure patterns.