sebastianbergmann / php-code-coverage

Library that provides collection, processing, and rendering functionality for PHP code coverage information.
BSD 3-Clause "New" or "Revised" License
8.82k stars 374 forks source link

Implement processed code coverage data mapper #1028

Open AndrewFeeney opened 10 months ago

AndrewFeeney commented 10 months ago

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 of SebastianBergmann\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 https://github.com/sebastianbergmann/phpcov/issues/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.

{
   "lineCoverage": [
       // ...
   ],
   "functionCoverage": [
       // ...      
   ],
}

I have not attempted to include any of the meta data that might be used to instantiate a Driver or Filter instance which are required to instantiate a CodeCoverage 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, perhaps driver and filter 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 to ProcessedCodeCoverageReport. 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.

AndrewFeeney commented 10 months ago

I see that there are some CI failures which I'll take a look at next. I also should mention that my implementation here is laughably simple. One thing I haven't looked at is validating the JSON on unserialization. I'm not sure if that's necessary or not, but I can have a go at that if you'd like.

codecov[bot] commented 9 months ago

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 84.09%. Comparing base (d10b53a) to head (d551ba9). Report is 93 commits behind head on main.

Additional details and impacted files ```diff @@ Coverage Diff @@ ## main #1028 +/- ## ============================================ + Coverage 84.00% 84.09% +0.09% - Complexity 1194 1196 +2 ============================================ Files 71 72 +1 Lines 4238 4250 +12 ============================================ + Hits 3560 3574 +14 + Misses 678 676 -2 ```

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.