As seen in #849, there are segments of the JSON codebase that are lacking test coverage. Since this is a core Ruby library, it would be befitting to have a robust test suite.
Personally, I tend to use Simplecov for projects, but in the case of JSON, that may be difficult/impossible due to the require sequencing. I've spent some time putting together a rudimentary prototype coverage using Ruby's Coverage module directly, so something should be possible, even if it is a grotty txt file. An ideal system would be simple to view and integrate with other tools, though, so I'm tempted to try and go further.
To that end, I've got a few questions:
- Is there a preference for coverage tool or output format?
- Is there any policy/preference regarding adding development dependencies?
- Are there any sneaky pitfalls that I'm missing? (eg. someone has tried this before and it went real bad)
The only pitfalls I can think of so far are:
- JSON is a core library, so getting the coverage tool to notice it properly with any dependencies possibly invoking it early might be, uh, fun
- There are segments of the test suite that have guards on them (eg.
ENV["JSON_COMPACT"])
- This wouldn't provide any coverage reports for the non-Ruby segments of code, of course, but any coverage is better than no coverage.
As seen in #849, there are segments of the JSON codebase that are lacking test coverage. Since this is a core Ruby library, it would be befitting to have a robust test suite.
Personally, I tend to use Simplecov for projects, but in the case of JSON, that may be difficult/impossible due to the require sequencing. I've spent some time putting together a rudimentary prototype coverage using Ruby's Coverage module directly, so something should be possible, even if it is a grotty txt file. An ideal system would be simple to view and integrate with other tools, though, so I'm tempted to try and go further.
To that end, I've got a few questions:
The only pitfalls I can think of so far are:
ENV["JSON_COMPACT"])