Implement processed code coverage data mapper #1028
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is my first pass at implementation for an object
SebastianBergmann\CodeCoverage\Data\ProcessedCodeCoverageDataMapper
which serializes to JSON and de-serializes from JSON a given instance ofSebastianBergmann\CodeCoverage\Data\ProcessedCodeCoverage
.The intention here is to move in the direction of being able to generate code coverage reports that do not require the serialize() and unserialize() PHP functions, and instead rely on a data only JSON format which might be less prone to issues such as sebastianbergmann/phpcov#109. This PR attempts to implement a basic JSON format only, and does not fully realize that goal by replacing the current implementation of serialization or documentation.
The JSON format have essentially represents the underlying data in the class. i.e.
I have not attempted to include any of the meta data that might be used to instantiate a
Driver
orFilter
instance which are required to instantiate aCodeCoverage
instance.I'm not sure if it would be better to make the JSON format more general, and nest the above properties under something like
coverage
using other keys, perhapsdriver
andfilter
or something else to include other meta data about the code coverage report. I have omitted this based on your stated preference to de-serialize toProcessedCodeCoverageReport
. I would welcome your guidance here.I'm still familiarizing myself with the codebase and the shape of the coverage data, so I'm not certain I've covered everything I need to in testing.
I've included one "End to End" style test for XML which may not be appropriate to merge. This was more about me ensuring that I had everything I needed to replicate a known expected XML report. I'm not sure how far to go down this path in adding more tests like that, as it may be redundant, and I don't want to be retesting the XML report generation implementation. Once again, I'd welcome your opinion here.