New api for Mutant about stryker-js HOT 6 CLOSED

Saving the Mutant JIT in the correct folder seems like a good idea to me :)

The API has to be extended in order for this to work. The Mutant has to know its original location, so it can overwrite the correct file.

I would suggest changing the save method of Mutant to accept a parameter foldername so the mutant knows where to save the mutated code. I think a revertOriginalCode method could also be a part of the Mutant class.

The Mutant also has to have knowledge of the Mutation which has been applied for the reporter.

from stryker-js.

I would like that saving of the mutant to disk is not the responsibility of
the mutant anymore. I think separation of concerns is in order here. The
figuring out which folder/file to save to should be coordinated by the same
class that is responsible for copying the files per test runner.

On Tue, Mar 8, 2016 at 8:54 AM, Simon de Lang [email protected]
wrote:

Saving the Mutant JIT in the correct folder seems like a good idea to me :)

The API has to be extended in order for this to work. The Mutant has to
know its original location, so it can overwrite the correct file.

I would suggest changing the save method of Mutant to accept a parameter
foldername so the mutant knows where to save the mutated code. I think a
revertOriginalCode method could also be a part of the Mutant class.

The Mutant also has to have knowledge of the Mutation which has been
applied for the reporter.

—
Reply to this email directly or view it on GitHub
#42 (comment).

from stryker-js.

I'm fine with some other class saving/restoring the code as long as the Mutant knows the (origina realtive) path to the file for which it has the mutated code

from stryker-js.

How about this api:

interface MutantInfo {
  location: ESTree.SourceLocation;
  fileName: string;
  mutatedNode: ESTree.Node;
  status?: MutantStatus;
  substitution?: string;
}

The idea is that a Mutation only has to set the location, filename and the mutatedNode. The Stryker framework will than go on and set the status and substitution.

The positive thing is that we can reuse this object for reporting as well as creating mutants. The bad thing is that it could be unclear for mutation plugin developers in the future. But i guess we could split it when we want to in the future.

from stryker-js.

I removed the milestone, as we agree to not put this new API in the v1 release

from stryker-js.

https://github.com/stryker-mutator/stryker-api/blob/master/src/report/MutantResult.ts

from stryker-js.