Dynamic Slicing

[Lms24]

For computing checked coverage, we have to create a dynamic slice using the tool Slicer4J.
After hours of figuring out how to work with this tool, we finally figured out how to compute the dynamic slice of a test case's statement.

We used the python script for it, as it provides a nice facade to hide the slicer's complexity. Especially for TC dynamic slicing this is extremely helpful.

Prerequisites

• The project for which the slice is calculated has to be compiled and a fat jar, containing all main and test classes plus additional libraries has to be created before calling the slicer. Since fat jars usually only contain main classes and their libraries, I shall therefore call this type of jar "extra fat jar" or for shits and giggles "Alfred Gusenbauer Jar" (AG-Jar).

To create such a jar, we used gradle for our projects. However, this is a cumbersome task, considering that gradle syntax seems to change weekly and almost no Stackoverflow et al. answers are usable without modifications. Therefore, we find our first challenge:

• Figure out how to universally create AG-jars w/ test classes #2

Executing the Dynamic Slicer

Now that we have our AG-jar, we need to call the slicer. Slicer4J works in three steps:

1. Instrument the Jar.
2. Execute the Jar (either via a TC/TM specification or via a main method spec) and collect the execution trace.
3. Create a backward slice from the execution trace based on supplied slicing criterion

As already stated, it's best to use the python script. It is called in the following way:

python3 slicer4j.py
-j <path-to-AG-jar>
-o <output-directory>
-b <slicing-criterion> 
-tc <full test class name>
-tm <test method name>

An example call from the Slicer4J/scripts directory:

python3 slicer4j.py
-j ../../../../master-utils/build/libs/testJar.jar
-o utils-out/
-b "at.tugraz.ist.stracke.jsr.CalculatorTest:39"
-tc "at.tugraz.ist.stracke.jsr.CalculatorTest"
-tm "divideZeroByNotZero"

Problems:

During compilation we observed some JDK level problems:

• The slicer and the slicing core have to be compiled with JDK-8 (at least on my system, else I get JAVA_HOME not set errors)

• The provided JUnit runner's and the test classes' JDK levels have to match and the SUT's syntax has to be <=JDK-9.

• Challenge 2: Ensure JDK compatibility levels

The provided JUnit runner is a problem in itself, as it only supports JUnit 4 (which is ancient IMO).

• Create a JUnit 5 runner and let it be user-selectable which runner to execute #3

Result

The results from the slicer should be pretty straight forward to work with:

• slice.log is a log file containing the java statements that are in the slice. They are ordered by execution, not by backward slice order.
• slice-graph.pdf gives us a nice dot graph to manually inspect the slice
• trace.log_icdg.log contains the intermediate statements from the trace which is used for slicing

Debug log files:

• instr-debug.log contains code instrumentation output
• trace_full.log contains trace output
• slice-file.log contains slicing output
• graph-debug.log contains graph creation output

Overall conclusion

With a few challenges in mind, we can conclude that we can use Slicer4J for dynamic slicing. Thus, checked coverage can be computed. The main challenge will be to create a robust interaction between JSR and Slicer4J to ensure that the slicing is executed correctly and robustly against e.g. different JUnit versions, JDK versions, etc.