sf / sfdx command to retrieve coverage report for each class and trigger under unlocked package

[honeyverma]

Is your feature request related to a problem? Please describe.
While maintaining compliance with the company's code we need to check the code coverage for each class/trigger while raising the Pull Request.

And we have Ci-CD pipelines in github actions that create package versions for the pull request using sfdx cli.

Now, we know sfdx already validates the coverage for all classes before finalizing the version. However, our pipelines also check the coverage of each class, because we try to maintain 90% coverage of each file.

Using sfdx package version report -p "<alias>" we can only see the overall coverage but we want to see coverage for each file

What are you trying to do
We want to see the coverage for each file for specific package version/alias

Describe the solution you'd like
We want a new command that can give us the report of coverage of every class and trigger in JSON format:

Describe alternatives you've considered
Right now we don't have any solution and our compliance shows that we have 0% code coverage, because we can't fetch it

Additional context
We don't want to run the test specifically, because then we need to create scratch org in pipelines, then install dependencies, then package, run the test then create a version. It would make our process slow and we have many packages

[github-actions[bot]]

Thank you for filing this feature request. We appreciate your feedback and will review the feature at our next grooming or sprint planning session. We prioritize feature requests with more upvotes and comments.

[git2gus[bot]]

This issue has been linked to a new work item: W-13634894

[AllanOricil]

Use Codecov or Sonar for this purpose. Both have quality Gates based on % of code coverage which you can add on ur pipelines

[honeyverma]

Hi @AllanOricil , we are using the sonarCloud but how can I retrieve the coverage for each class or trigger?

[AllanOricil]

there are some flags u can pass to sfdx to ask salesforce to compute and retrieve code coverage. Did you try it?

[AllanOricil]

Bear in mind that the code coverage reports returned when pushing source isn't working properly. You will need to change the file paths by hand, and if u have a class and a trigger with the exact same name, the code coverage for the class is overwritten by the code coverage of the trigger.

[honeyverma]

Thanks, @AllanOricil, but we need to ensure code coverage for each package version (unlocked), as explained in the description. It's not ideal to run the tests and then retrieve the results as it slows down the process. Moreover, all tests are already executed during the creation of each package version, so running them again would be redundant and inefficient. Creating a scratch org as part of our pipeline process would add an additional 10-15 minutes for each push, which is undesirable. Therefore, we are requesting Salesforce to develop a command that allows us to access the previously computed test results for each package version. This would significantly improve efficiency and streamline our workflow.

[AllanOricil]

You can try to query ApexCodeCoverageAggregate using the tooling api until they add flags in this command for ur needs

[AllanOricil]

Here are some sources to help u

https://salesforce.stackexchange.com/questions/1609/how-can-i-get-code-coverage-programatically-through-apex

https://developer.salesforce.com/docs/atlas.en-us.api_tooling.meta/api_tooling/tooling_api_objects_apexcodecoverage.htm

https://developer.salesforce.com/docs/atlas.en-us.sfdx_cli_reference.meta/sfdx_cli_reference/cli_reference_force_data.htm#cli_reference_force_data_soql_query

[honeyverma]

Thanks @AllanOricil, Although we are aware of these basic solutions, it is important to note that they are designed for normal source code without a packaging system. Our specific requirement involves achieving code coverage by each package version for each file. For instance, let's consider the class "ClassA," which has a code coverage of 90% in version pkgA@9.2.1-2, but it may have a coverage of 87% in version pkgA@9.2.1-3. Hence, it is necessary to maintain coverage for all package versions.

Furthermore, even if I compromise on the coverage for package versions and choose to focus solely on the latest test coverage, the aforementioned solutions are organization-dependent. As previously mentioned, we create package versions that are not tied to any specific organization. Salesforce itself generates a dummy transient scratch org to execute tests and validate metadata at the time of creating the version then stores the results in a database. Unfortunately, this org cannot be accessed by us or anyone else. Consequently, we cannot utilize SOQL, Tooling API, Apex, or any other related processes.

[AllanOricil]

I don't get why would one get code coverage after creating the package. You create packages from commits that have passed through your quality gates when integrating new changes. This means that packageA@9.1.2-2 would already have code coverage per class/trigger available since it was created from a commit that passed ur ci pipeline. The code coverage is bound to the commit hash that u used to create your package version, and the environment u used for ci is one that you own and validated that the changes are fine.

[honeyverma]

As mentioned earlier, it is essential for us to maintain compliance. I would like to emphasize that Salesforce currently accepts any file with 75% code coverage or higher. However, in our case, we diligently write tests for all use cases and end-to-end scenarios. To ensure thorough coverage, we aim to achieve a minimum of 90% code coverage. Anything below this threshold would raise concerns for us, and coverage below 95% would be considered a warning.

To enforce this requirement, we expect SonarCloud to block the merging of pull requests if any class or trigger within the package version falls below the 90% coverage threshold. This will help us maintain the desired level of code quality and ensure comprehensive testing.

[hungrypipo]

This is a useful feature we could definitely use this too

[mcarvin8]

Feel free to use my Salesforce CLI plugin for Sonar - https://github.com/mcarvin8/apex-code-coverage-transformer