Gather coverage for "some targets" with Swift Packages?

I have an xccov parser I've been using to gather coverage details for a library I've recently moved from an Xcode project to a package. The coverage format output by

swift test --enable-code-coverage

is incompatable, so I've been using

xcodebuild test -scheme PACKAGE_NAME -enableCodeCoverage YES -resultBundlePath ./build.xcresult

to build and run tests with Xcode, instead. This works pretty well, in that I can use

xcrun xccov view --report --json ./build.xcresult > coverage.json

to get coverage info in the format my xccov parser understands. The problem is this gathers coverage for all targets, including dependencies.

In Xcode-project-world, I solved this issue by configuring my scheme to "gather coverage for some targets" and adding just my target to the list. But there's no scheme in my Swift Package, and there doesn't seem to be a configuration or command like param that does anything similar?

Alternately, I could tell xccov to report coverage for just a specific target using something like:

xcrun xccov view --report --json --files-for-target PACKAGE_NAME ./build.xcresult > coverage.json

but this generates a some weird subset of the standard xccov json that causes my parser to barf all over itself.

So. Is there some swift package or xcodebuild equivalent to setting "gather coverage for some targets" on a scheme? If not, is there some way to make xccov filter coverage for just the given targets without throwing out the rest of the JSON parsers expect?

Or am I going about this all wrong, and ought to be using something else?

Yes, the two formats are different. (But in my experience the package manager’s is actually much easier to work with.)

Yes. This is how both Xcode and the package manager handle packages.

They have no such customizability that I know of.

I solve this during post‐processing. My methods for loading coverage data into Swift, excluding dependencies, are here:

You can depend on the package directly, or use the source code as a reference while you write your own.

And here is an example of the report being further culled after loading, to also filter out executable targets, test targets, custom paths and custom inline directives.

What about customizing the PACKAGE_NAME scheme?

Terms of Service

Privacy Policy

Cookie Policy