stryker-mutator
feat: adding dotnet metric report
Description:
This is a draft for a metrics solution for dotnet.
The initial idea was to create a nuget package capable of interpreting a stryker-report.json file and returning the corresponding metrics.
I took advantage and created a CLI with the aim of interpreting a file and returning it to the console in a structured way.
I would like your opinion on this implementation, I looked at the PR for scala and tried to do something similar.
I had questions about nomenclature and folder organization.
Just linking the initial PR
I think this implementation goes beyond the scope of what we want to provide with mutation testing elements, by providing a CLI that reads a json file and prints the score to the console.
I assume that this is the specific requirement you have for a package like this so I understand why you modeled it like this. However imo mutation testing elements should not go beyond the core of providing the programmatic schematic (model) of the report and the calculation methods that could be performed on this model. Any I/O should be provided by the consuming program.
I think a case can be made to provide json serialization like metrics-scala did, but even that might go too far.
However if I'm misinterpreting the intention here and the CLI package is only meant as an example instead of a release product then I think that's fine.
@hugo-vrijswijk @nicojs since you both have existing implementations I would ask that you weigh in on the scope of packages we want to provide.
since you both have existing implementations I would ask that you weigh in on the scope of packages we want to provide.
The main reason for the metrics packages is to have a single place per language that implements the metrics interface. IMO this is at least having a model for a result and being able to (correctly) calculate metrics based on the result. And each language might add features that are useful for it. Like aggregating reports for JS, or a type-safe JSON codec for Scala.
Non-Stryker programs probably get the most use out of the first part to calculate score or other metrics from a report. I agree that reading JSON from disk or a CLI that writes to stdout is maybe too specific for a package here
