Class JmlProgram has no javadoc description. Add a description for the class.

Test testGetSuccessors_emptyMethod in class StrykerRepairSearchProblemTest does not pass. This test evaluates getSuccessors(). Please have a look at it and resolve the problem.

Use Apache commons Configuration in Stryker

There is too many configuration arguments being passed through too many classes. A Configuration singleton class would amend this problem.

The implementation should support setting configuration values via methods and by using a configuration file (.properties extension maybe) and reading the values from it.

JMLProgram, to be renamed as JMLAnnotatedClass, has several protected attributes. This goes against its encapsulation. Change the visibility of these attributes to private, and define corresponding getter methods to access them. Update the project's code to use the getters instead of the attributes directly.

When attempting to repair a program, getSuccessors throws a null pointer exception. PRVO is involved.

To reproduce the bug, enable PRV* in MuJavaAPI, and run test

programRepairWithSimpleIncorrectMethodDepthTwo()

from test class BasicProgramRepairTest.

For the moment, I'm commenting PRV* so that all tests pass.

Currently, a fix candidate only holds information regarding the last performed mutation. This is fine for repairs that require only one mutation, but when more than one mutation is performed to fix a program bug, we do not have enough information on fix candidates to trace the change.

Solve this problem by storing on fix candidates the list of all mutations performed on a fix candidate. This issue involves:

• change FixCandidate attribute:

  protected MutantIdentifier mutation;

  to a list of MutantIdentifer objects (name it mutations).

• update FixCandidate constructors to create this list empty, for the initial candidate, and create a singleton list with a mutant identifier, when provided.

• provide an additional constructor that receives a list of mutant identifiers, to set mutations.

• method equals MUST NOT take into account the mutations; leave this method as is.

• update MuJavaAPI.generateMutants to append new mutations in the list of the fix candidate from which mutants are generated.

• in BasicProgramRepairer.repair(), when a solution is found (outcome is true), print out the mutations leading to the solution (just a description of the mutation, and if the info is available, the line where the mutation was applied).

• test your solution.

When repairing a class with an explicitly given package, if a solution is found its location is wrongly reported: dots are used to separate packages in the location, instead of /.

Example:

/tmp/mutants/4LE798UCII/from_-2293123-74-78114-554380-65219710821-84-68/adt/SinglyLinkedList/contains/PRVOR_REFINED/0/adt.SinglyLinkedList.java

Should be:

/tmp/mutants/4LE798UCII/from_-2293123-74-78114-554380-65219710821-84-68/adt/SinglyLinkedList/contains/PRVOR_REFINED/0/adt/SinglyLinkedList.java

Add a mutation attribute to class FixCandidate, of type mujava.api.MutantIdentifier. This attribute will be null for the initial fix candidate (that does not come from any mutation), and will be set with the mutant identifier that led to the candidate for all other cases.

A new option to the CLI should be added to allow users to select between dfs and bfs search strategies.

Implement a search engine that performs bounded depth first search, but iteratively instead of doing so recursively.

This allows us to have control over the stack of opened configurations (those that remain to be explored), and will help us implement pruning techniques.

StringOutOfBoundsException is raised in method wrapMutant of class MuJavaAPI. To reproduce the problem, disable mutator OAN, and run test:

programRepairWithSimpleIncorrectMethodWithDepthOne_usingDependencies_multikeymap()

in test class BasicProgramRepairerTest.

A preliminary profile of Stryker shows that mujava.app.Reloader.loadClassData takes more than SAT. Improve this routine to make it more efficient.

Null tests (tests that do not compile) are stored as collected tests for RAC. It should be checked that a junit test resulting from recovering the inputs of a SAT verdict does compile correctly, to avoid collecting invalid tests.

Location of a program (folder where the file can be located) must end with a slash. Make sure that paths are passed this way.

Method success(FixCandidate s) in class StrykerRepairSearchProblem must be implemented. This method needs to call TACO to check if the candidate does not violate its specification.

Candidates must be modified and compiled to work with jmlrac but only to run junit tests. So the following changes should be made.

put the necessary code to modify and compile the jmlrac version of a candidate in RacAPI#runJunits

compile the original candidate just before running TacoAPI#isSat (maybe move the compile code inside that method?)

Method getMd5Digest() must be implemented in class JmlProgram. This method returns the md5digest of the program file, disregarding comments (including mutGenLimits) and blank spaces.

Use method mujava.util.JustCodeDigest#digest(File):byte[] to obtain it.

In class constructor, the attribute program is given new File(className) and it should be given

new File(sourceFolder+className+".java")

Assuming that sourceFolder ends with a system path separator

Tests for BasicProgramRepairer are too slow. Simplify tests and testing classes to be able to run repairer tests quickly.

Currently the overriding properties are set inside method success on each call. Overriding properties should be set when creating an instance of StrykerRepairSearchProblem.

1. Add an attribute public Properties overridingProperties
2. add constructor public StrykerRepairSearchProblem(JMLAnnotatedClass, String, Properties)
3. add constructor public StrykerRepairSearchProblem(JMLAnnotatedClass, String, String[], Properties)
4. use overridingProperties field inside success method instead of defining a new Properties instance

So far, BasicProgramRepairer only informs whether a fix has been found or not, but does not indicate where to find the fix. Implement routine getSolution() in BoundedIterativeDepthFirstSearchEngine, so that, in case a fix was found, BasicProgramRepairer can retrieve it.

When calling the constructor for StrykerRepairSearchProblem with "" as method name an IllegalArgumentException("no method to fix") should be thrown.

JmlProgram instances have, at the moment, file name and location. This must be changed to location and qualified class name. File name can be obtained from this information.

RepairCLI should use Properties to set the parameters to PrivateStryker

A breadth first search engine is available, but is not bounded. Implement a bounded breadth first search engine, to offer as a search strategy in BasicProgramRepairer.

This class should offer the following methods

• given a repairer.FixCandidate object, a method name and a list of mujava.api.Mutant objects (mutation operators) generate a list of FixCandidate objects, each one representing a mutant.

NullPointerException is raised when using OAN mutator on MultiKeyMap example. To reproduce the problem, run test

programRepairWithSimpleIncorrectMethodWithDepthOne_usingDependencies_multikeymap

in test file BasicProgramRepairerTest

When calling hasMethod with an empty method name an IllegalArgumentException("empty method name") should be thrown

Comments accompanying attributes in class BasicProgramRepairer are not javadoc. Change these attributes to javadoc format.

Projects Stryker depends on must be correctly configured to work with Maven. Otherwise, no Maven build functionality works appropriately.

Create a Maven repository for projects Stryker depends on.

BasicProgramRepairer only uses bounded dfs as search strategy. Allow users to select which strategy to use for search.

Implement a basic command line interface for BasicProgramRepairer, so that the tool can be called from the command line, passing the files to be repaired.

Method setMaxDepth, for setting the maximum depth to be considered when attempting to repair a program, must be available in class BasicProgramRepairer. Implement this method, represent max depth appropriately, and make sure repair() takes into account this feature.

For each Library that stryker uses (Taco, muJava++, etc) there should be

• An API
• Documentation for the API
• Usage examples in the documentation

All messages in the tool should be in English. Change to English.

Constructors of class JmlProgram require program names to be given with the extension. This is contrary to the way most other tools in the project deal with program names (MuJava, TACO, JmlParser, etc.). Remove the extension form the program name and add it to the file name when creating it.

JMLProgram actually represents a JML annotated class. Rename JMLProgram to JMLAnnotatedClass. Make sure all class names in the project, comments, etc., are appropriately updated.

Running test case programRepairWithSimpleUnrepairableIncorrectMethodDepthOneInBfs of BasicProgramRepairerWithRacTest do pass but there's an Error initializating test reported caused by not finding the method to run. The method should be found so this is probably a bug.

This need to be addressed quickly.

equals receives a FixCandidate, not an arbitrary State. Correct this problem and update method implementation.

When running test programRepairWithSimpleIncorrectMethodWithDepthOne_usingDependencies_multikeymap defined in class BasicProgramRepairerTest cause a NullPointerException with the following trace

java.lang.NullPointerException
at ar.edu.jdynalloy.xlator.JDynAlloyXlatorVisitor.fill_object_invariant_predicates(JDynAlloyXlatorVisitor.java:1022)
at ar.edu.jdynalloy.xlator.JDynAlloyXlatorVisitor.fillPredicateTables(JDynAlloyXlatorVisitor.java:969)
at ar.edu.jdynalloy.xlator.JDynAlloyXlatorVisitor.visitProgramToCheck(JDynAlloyXlatorVisitor.java:677)
at ar.edu.jdynalloy.xlator.JDynAlloyXlatorVisitor.visit(JDynAlloyXlatorVisitor.java:652)
at ar.edu.jdynalloy.ast.JProgramDeclaration.accept(JProgramDeclaration.java:183)
at ar.edu.jdynalloy.ast.JDynAlloyVisitor.visit(JDynAlloyVisitor.java:263)
at ar.edu.jdynalloy.xlator.JDynAlloyXlatorVisitor.visit(JDynAlloyXlatorVisitor.java:336)
at ar.edu.jdynalloy.ast.JDynAlloyModule.accept(JDynAlloyModule.java:179)
at ar.edu.jdynalloy.xlator.JDynAlloyTranslator.translateAll(JDynAlloyTranslator.java:166)
at ar.edu.jdynalloy.xlator.JDynAlloyTranslator.translateAll(JDynAlloyTranslator.java:42)
at ar.edu.taco.jdynalloy.JDynAlloyToDynAlloyManager.process(JDynAlloyToDynAlloyManager.java:55)
at ar.edu.taco.engine.JDynAlloyStage.execute(JDynAlloyStage.java:142)
at ar.edu.taco.TacoMain.run(TacoMain.java:460)
at tools.apis.TacoAPI.isSAT(TacoAPI.java:117)
at repairer.TacoSuccessCheckStrategy.isSuccessful(TacoSuccessCheckStrategy.java:59)
at repairer.StrykerRepairSearchProblem.isSuccessful(StrykerRepairSearchProblem.java:155)
at repairer.StrykerRepairSearchProblem.isSuccessful(StrykerRepairSearchProblem.java:1)
at search.engines.BoundedDepthFirstSearchEngine.iterativeDepthFirst(BoundedDepthFirstSearchEngine.java:118)
at search.engines.BoundedDepthFirstSearchEngine.performSearch(BoundedDepthFirstSearchEngine.java:98)
at repairer.PrivateStryker.repair(PrivateStryker.java:226)
at repairer.BasicProgramRepairerTest.programRepairWithSimpleIncorrectMethodWithDepthOne_usingDependencies_multikeymap(BasicProgramRepairerTest.java:248)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)

Implement method hasMethod(String methodName) in class JmlProgram. This method simply checks if a given methodname corresponds to a method of a class.

Method getSuccessors(FixCandidate s), which computes the successors (mutants) obtainable from a given fix candidate, must be implemented.

This method uses muJava to compute (all) mutants of a given fix candidate, taking into account the mutation limit comments (comments at the end of some lines, indicating which lines should be mutated).

"All mutants" means, for this issue, all mutants obtainable from all available mutators, except those that apply to the left hand side of assignments.

A JML program represents a JML annotated class. A repair problem needs then, besides a JML program, the name of the method to fix.

Add attributes to class StrykerRepairSearchProblem that represent this information, and methods to access and use it.

Maven is not running tests in the project. It might have to do with test classes names. Make sure tests are run when running project build test.

The className attribute should be transformed replacing each dot with a system path separator and a system path separator should be appended to sourceFolder if necessary.

There are several error messages printed using System.err.println(String) method that doesn't have information regarding where the error is being detected.

System.err.println(String) method call should be rewritten to #:

So far, Stryker has no support for relevant classes. As a consequence, the only relevant class to be considered for the repair is the class containing the method to repair.

Add support for relevant classes. Relevant classes are represented as a string, e.g.,

"examples.bintree.base.BinTree,examples.bintree.base.Node"

This issue involves the following tasks:

• add an attribute to BasicProgramRepairer to hold the relevant classes. By default, relevantClasses only hold the class containing the method to fix.
• add constructors to BasicProgramRepairer that enable the creation of instances by passing, besides other necessary parameters, the relevant classes. DO NOT REMOVE existing constructors; provide new ones.
• add an attribute to StrykerRepairSearchProblem to hold the relevant classes. By default, relevantClasses only hold the class containing the method to fix.
• add constructors to StrykerRepairSearchProblem that enable the creation of instances by passing, besides other necessary parameters, the relevant classes. DO NOT REMOVE existing constructors; provide new ones.
• update method success in class StrykerRepairSearchProblem to pass relevant classes when calling TACO, when relevant classes are provided.
• add command line options to RepairerCLI, to optionally provide relevant classes when calling Stryker from the command line.
• add/update appropriate javadoc comments to modified/introduced routines and attributes.
• add tests to verify that your modifications work as expected.

Tests of Stryker are now well structured using parameterized tests. However, tests of Stryker with and without RAC are merged in a single test class. Separate these tests in different testing classes (maintaining the parameterized nature of the tests) so that profiling can be more easily performed.

parentPath in class JmlProgram is not a parent path. It is the source folder where the class/file is located. Rename the attribute parenthPath, update the names of parameters, and documentation (javadoc comments).