function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion
adreameradreamer 

Package installation failures

Hi All,

 

I am using a dev org to do the packaging. In this org the test coverage is over the required limit, and I managed to upload the package.

 

When trying to install the package I get a long series of errors during a package (managed-beta) installation, and all the failures share in common the they occur in test methods and are always same problem: System.QueryException: List has no rows for assignment to SObject.

 

The test methods where the installation fails share a common pattern. In each Apex class I have a static method initData where I intialize and insert the records required in the test methods. Then the test methods first of all call this initData() method, and then I fetch records.  For instance:

 

static void initData()

{

   MyObject__c obj = new MyObject__c(Name='Hello');

  insert obj;

}

 

static testmethod void test1()

{

  initData();

 List<MyObject__c> objs = [select Id, Name from MyObject__c where Name='Hello'];

 if(objs.size() > 0)

  {

    .......

  }

}

 

I believe the line in red is the one that is causing the exception System.QueryException: List has no rows for assignment to SObject during the installation of the package.

 

What I don't understand is why this fails during installation but doesn't fail during running of the test methods and package upload.

 

Any ideas ?

 

Thanks,

Fernando

 

 

Best Answer chosen by Admin (Salesforce Developers) 
ReidCReidC

Every time I've run into that I've been able to trace it down to the data I want not actually being available.  In your example, I would start by making sure the running user for your test has access to the data your app initialized and that the data is actually there.

All Answers

ReidCReidC

Every time I've run into that I've been able to trace it down to the data I want not actually being available.  In your example, I would start by making sure the running user for your test has access to the data your app initialized and that the data is actually there.

This was selected as the best answer
adreameradreamer

Hi ReidC,

 

Thank you for your prompt response.

 

There are two parts in your response: data availability during running of test and access to that data.

 

On the data being available for the running tests this is done in the initData() method. I have asserts in the test methods that check the proper function of the code so I think this proves that when running the test methods in the packaging org the data is available. Btw, the packaging org has not data at all and that was done on purpouse.

 

On the running user for the test methods I think this is probably what is causing the failures during package installation, unlike no failures when running the same tests in the packaging org. Since according to the previous paragraph I think I can be pretty certain that the data is available for the test, it must be that the running user while performing the tests in the org I am installing it has no access to the data.

 

When I create the package the API Access is set to Unrestricted. Moreover, if I drill into the link I see the message Components in this package will have the user's full API access to the following custom objects included in the package: Does this mean that the installing user will have full API access -i.e. CRUD to the custom objects in the package ?. Also, when installing the package I install it as system admin.

 

What else I should do to make sure the test methods running user has full access to the test data created during test methods run ?

 

Thanks again for your help !

Fernando

aalbertaalbert

I am not entirely sure the line highlighted in red is throwing the error. When you return a SOQL query to a List<>, it won't throw that error. The query just sets the List<> to null/empty. Usually that type of query exception is thrown when you make a SOQL query and return it directly to an sObject (and not a list of an sObject). 

 

I know the install error messages are not very detailed to show you the specific line number that failed. But I would take one test method that fails and verify that all queries would return data (or at least handle the queryException with a try/catch). 

adreameradreamer

Hi Albert,

 

Thank you very much for your response.

 

Following your advise I am focusing on one test method and follow it through to try to shed some light as to where the issue is. I always assing query results to a List<> of objects so as you say I don't think the issue is there. Also, every piece of code is within a try/catch block and some of the testing involves making it to fail to test that too.

 

What confuses me is that running all the tests in the packaging org does not throw any exception. The packaging org has no data at all so the test methods relay on the test data created for them, and in that respect is the same as the installation target org. The issues arise during installation but not during testing or creation of the package in the packaging org.

 

On a related note I managed to install the package by setting the checkbox "Ignore Apex test failures ...." in the last step of the installation. I am not sure I like the sound of it, this is why I haven't tried it before. What does this flag do ?. It skips running all the tests during installation ?

 

I will investigate some more to get to the bottom of this.

 

Thanks again.

Fernando

adreameradreamer

Hi Albert and ReidC,

 

As it turned out there was a piece in the test data intialization code that was relying on the Standard Price Book which involved a query to bring up the book ID, and was assigned to a single object rather than a List<>. Then, as the book was inactive in the installing org, this piece was causing the exception. So you both were spot on.

 

Once fixed I can now install the packaga in any org without having to recurr to checking the flag to prevent test failures to make the installation fail.

 

Thank you both very much for your help !

 

Regards,

Fernando