Add a statement mutation operator

[sandybrownlee]

Not Java-specific as such but I think will be heavily slanted towards Java syntax. The idea is to look within statements for possible modifications. So e.g.:

• for operators, look for things that take the same arguments and return values (e.g. == =! > < are all mutually swappable)
• for an assignment, swap in a new variable or value for the RHS. This will mean maintaining a list of variables for the class (or possibly just for the parent statement so they are in scope)

[sandybrownlee]

As a first step, we'll need an abstract MutateStatement class, to extend Edit. Then extending that, we can have SwapOperator, SwapAssignment etc.

This will mean additions to Patch.randomEdit() and Patch.apply()

We will probably also need some clever tests to see where each of these is applicable, but as a start, we can just try them and let the compiler decide if they work or not.

[drdrwhite]

Cool. Are mutation testing operators relevant here?

Mujava - the most well-known mutation testing tool for Java. Paper: https://www.researchgate.net/profile/Jeff_Offutt/publication/221556141_MuJava_a_mutation_system_for_java/links/0046353b595e233b00000000.pdf

Table 2 in the paper on Judy, another mutation testing tool, has examples of mutation operators: http://madeyski.e-informatyka.pl/download/Madeyski10b.pdf

[drdrwhite]

The MuJava source is online, so could be used to mine operator implementations: https://cs.gmu.edu/~offutt/mujava/

[sandybrownlee]

Thanks, I've been finding that most helpful. A question: do was want edits to be immutable? One could imagine that an instance of MutateStatement will be tied to a particular statement, but be might want to change the mutation - say instead of swapping a 0 to a 1, swap to -1 instead. My instinct is to make it immutable - if we want to modify an edit we can just copy it and replace what its doing then.

[drdrwhite]

We should think about the purpose of creating these operators - we can discuss in our skype.

[drdrwhite]

Good skype, thanks all.

@sandybrownlee when you submit a PR please link to this issue.

Let's take detailed discussion to Slack, unless it is specifically about the implementation of a mutation operator.

[sandybrownlee]

In the interests of clarity I'm switching from "MutateStatement" to "ModifyStatement"...

Placeholder: for now I've added a single extra block to Patch.randomEdit() which will add a new LogicalOperatorReplacement. It's debatable whether we should either (a) decide we're adding a ModifyStatement, then choose which kind of modification to do; or (b) make the different modifications top-level - so the same chance of being created as copy/delete/move statement edits.

[drdrwhite]

Don't overthink it - as Gin is designed to be hacked, we don't have to be backwards-compatible... yet... "move fast and improve things".

[sandybrownlee]

Thanks :)

Nearly there with this. I've created a "swap operator" edit, which will swap e.g. == for a !=, or * for a /. A little more testing in the morning.

For those interested in the meantime, the changes are here - https://github.com/sandybrownlee/gin