3

As the title says, I'm trying to deploy some code and metadata from a sandbox to another. The deployment compiles successfully, and the tests pass too, but the deployment fails with the "Code coverage error" message.

The weird thing is that no coverage errors are shown. Usually it displays to the user which class is missing coverage, and how many lines are covered by the tests that were run.

no classes are shown

What can be causing this?

Note: both environments are on API 44 (Winter '19). This is a single-language org, so the interface is in portuguese. But as you can see, no classes are listed.

Improve this question
7
  • Can you share a screenshot? My guess is that you either have Apex Trigger(s) without any coverage (although, you typically will see which ones have 0% coverage) or your Total Org Coverage is below 75%
    – Bob Lopez
    Commented Sep 13, 2018 at 20:35
  • No triggers in the package. I'll upload a screenshot in a moment. There is one trigger involved in the contents, which is related to the Case object. But I'm using a trigger handler framework (I have one line on the trigger which calls a class to handle the different contexts, so if there's coverage issue on the trigger, this class should be showing).
    – Renato Oliveira
    Commented Sep 13, 2018 at 20:37
  • I suggest you switch language to english -- sometimes salesforce errors are not consistent in case of non-english language
    – kurunve
    Commented Sep 13, 2018 at 21:28
  • Can't change the language to English. It is a single language org.
    – Renato Oliveira
    Commented Sep 13, 2018 at 21:28
  • I am sorry, haven't seen that. As an option, I can suggest you to retrieve changeset content using ant or workbench (linkedin.com/pulse/…) from source org and deploy to target -- probably that will give more information
    – kurunve
    Commented Sep 13, 2018 at 21:36

2 Answers 2

Reset to default
11

I encountered the same issue as recently. We have an appexchange app that handles deployments to different orgs using the Metadata api. Since we upgraded we got support cases mentioning that the deployment was running all good, no test failures reported but there was a code coverage error without specifying how much percent is missing (what is the normal behavior). And even if the org had more than 75% apex coverage.

After digging deeper in the issue we found the following cause:

Since Winter'19, API version 44.0, Salesforce is also checking code coverage on flow as soon as they are deployed as active. You can find the information in these release notes:

However the release notes state that this should be activated on the org and if not active the coverage is not applied. Again some deeper investigation from our side and we found that the setting is only available on production orgs (default false) but not on sandboxes. So deployments to sandbox always seem to calculate code coverage on flow or process builders. This was causing the deployments to fail unexpectedly, we found the actual error message in the FlowCoverageWarnings object received from checkDeploymentStatus method in the metadata api.

I'm not a 100% sure that what you encountered has the same cause, but I'm inclined to say it is.

I see only two options to avoid this in the future, either don't run tests deploying to sandbox (not really advisable) or provide test classes that cover process builder / flow logic so that it provides >75% on them.

Hope this helps you further!

Improve this answer
1
  • God, I wonder how much time you spent on this... Thank you for your answer. This seems to be the cause.
    – Renato Oliveira
    Commented Oct 30, 2018 at 13:31
0

Tests passing doesn't necessarily mean that you have adequate coverage. You could run in Developer console from the original org and see what your coverage percentage is. If these are not identical orgs, you will run the risk of your additions pulling already low coverage down further in your target org due to the increase of lines of code overall with your code.

I would suggest taking an audit of your code on both ends to ensure your coverage at your target org is as high as you can get it, as well as the code you're deploying also being as close to fully covered as you can make it.

You may find that the coverage in your target org was already quite low due to required field changes which may cause a test class to become outdated as it may no longer meet conditions to enter certain blocks of code if the test classes are poorly maintained.

Developer Console View of Coverage and classes without coverage: Example View Of Coverage

Improve this answer
4
  • Coverage isn't the direct issue here. The problem is the platform not displaying which class is not covered. All classes in this package are properly covered in the original environment. If I don't run the tests for a specific class, for example, the deployment fails and the platform tells me that this specified class is not covered.
    – Renato Oliveira
    Commented Sep 14, 2018 at 12:59
  • well the issue i see from your above Screen shot is that all classes are covered - but not enough overall to meet the 75% minimum coverage required, this is why i say you should assess where your coverage is lacking and can be picked up. The platform doesn't display which classes are not covered in general, the only time it will list specifics not covered is when the uncovered code is an Apex Trigger which requires at least 1% coverage for any triggers. Apex Classes, have no minimum requirements per instance, just an overall 75% for all classes collectively.
    – Ronnie
    Commented Sep 15, 2018 at 5:55
  • Please refer to this article for some better information about how it is calculated: help.salesforce.com/…
    – Ronnie
    Commented Sep 15, 2018 at 5:58
  • If your example in this comment thread is in reference to packaging a managed product and it tells you that data, you won't get that from deployment details like the one you provided in your OP above. That is just a typical deployment screen that you will see when deploying unmanaged code from org to org.
    – Ronnie
    Commented Sep 15, 2018 at 6:11

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .