I did a "Run All Tests" in production instance and found out that the following.

a) Code coverage of all the classes is 76 %

b) 160 Test class failures are shown (101 from apex test classes and the other 59 errors from managed packages)

There is not a single developer except me as of this moment in this organization and there is a pressing need to release a couple of fixes. Those fixes required Apex class changes which I already completed in sandbox.

I really need some help for the following queries

  1. Will it be possible for me to deploy one Apex class with all these test class failures? I can ensure that the class which I am deploying is code covered and without any test class issues.
  2. I could see just 3 weeks back the previous developer has deployed a batch apex class + test class without any issues via change set. Can someone explain how that is possible to deploy an apex class with all these test class failures?
  3. I am hoping that the 59 test class failures from managed packages will not hamper code deployment of my apex classes. Can someone confirm this?


I did try pushing a previously failed changeset and I could see the following behaviour.

enter image description here

enter image description here

Whats puzzling me is that the salesforce changeset deployment process validated the changeset by running all apex tests and it complained about only 2 failures instead of all the 100+ failures (which I previously got by running "Run All Tests")...not able to understand how that is possible ?.

Does it mean that if I fix these two failures then will I be able to deploy the Apex changes ?...

  • 1
    Maybe a potential fit job for: appexchange.salesforce.com/… (At least the part about Org changes and validation rules) If you do not want to face this again it is worth a look
    – Eric
    Commented Sep 22, 2015 at 23:51

1 Answer 1

  1. You will not be able to deploy your Apex class with the 101 Apex test failures.
  2. The reason for the failure could have been introduced in the time since that deployment.
  3. The managed package test failures will not hamper your deployments.

The first thing I would check is what are the error messages that you are getting for your failures? My guess is some of the test failures are caused by the same issue. It is possible that all 101 failures are for the exact same issue.

Many times, these failures could not be code related at all, it could be a configuration change introduced in the destination org. Configuration changes such as these could cause test failures

Validation Rules - Lets say you have test code that updates a field on a record that passes in production. Once it's already in production if I create a validation rule that says I cannot update that field if another field is blank, since my code updates that record with that other field being blank, my tests that previously passed, will now fail

Making a field required on an object - Lets say you have test code that inserts a record that passes in production. Once it's already in production, I change a field on that object to make it required. If I have test code where I do not set a value for that field before inserting, my tests that previously passed, will now fail.

Lookup field filters - Lets say you have test code that or inserts a record and that record has a required lookup field on it that passes in production. Once it's already in production, I add a filter to that lookup field only allowing certain related records. If my test code relates a record that does not meet that criteria, my tests that previously passed, will now fail.

Its important to note that I'm not saying your issue is definitely one of these, but these are some common scenarios where an admin unknowingly introduces a configuration change that can cause a lot of test failures.


Based on your edit and the screenshot it looks like the error is based on having a non selective query against a large set of records. An explanation of why this passed before and fails now could be that your org just recently crossed the threshold of 100,000 records that meet your criteria.

@crop1645 brings up a good point as well, you are likely using seealldata=true, that is another way to solve this issue, but it may cause others as if you remove that then you will need to ensure you are creating all your test data. It is worth noting that seealldata=true is not best practice and it is recommended that you do create all your own test data.

Form the docs

More Efficient SOQL Queries

For best performance, SOQL queries must be selective, particularly for queries inside of triggers. To avoid long execution times, the system can terminate nonselective SOQL queries. Developers receive an error message when a non-selective query in a trigger executes against an object that contains more than 100,000 records. To avoid this error, ensure that the query is selective.

Selective SOQL Query Criteria

A query is selective when one of the query filters is on an indexed field and the query filter reduces the resulting number of rows below a system-defined threshold. The performance of the SOQL query improves when two or more filters used in the WHERE clause meet the mentioned conditions. The selectivity threshold is 10% of the first million records and less than 5% of the records after the first million records, up to a maximum of 333,333 records. In some circumstances, for example with a query filter that is an indexed standard field, the threshold can be higher. Also, the selectivity threshold is subject to change.

  • Thanks a lot for your detailed response..I have updated the post with my latest findings..can you take a look at it and respond plz ?
    – Varun
    Commented Sep 18, 2015 at 0:31
  • Just edited the answer Commented Sep 18, 2015 at 0:47
  • Chris...superb !!!...just one more thing...If I choose to remove the test methods which are calling non-selective SOQL I will risk less code coverage for that controller but atleast the changeset can be deployed ....Of course that is only when the org's code coverage is over 75 %...am i right ?
    – Varun
    Commented Sep 18, 2015 at 0:51
  • You are right, you are sacrificing code coverage, but it should work. It is worth noting though that this error could come up in production if you run the same scenario as the test code was running. This is a quick workaround, but I would, when your not under the gun, try to address this. Commented Sep 18, 2015 at 0:59
  • 1
    @ZenSeeker - non-selective queries means that some testmethod is using seeAlldata=true or is at v23 or lower (implicitly seealldata=true). Said testmethods should mock their data, not rely on org data
    – cropredy
    Commented Sep 18, 2015 at 1:26

You must log in to answer this question.

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