9

Short Version:

I am getting errors in 3rd party unmanaged packages that are preventing me from deploying any code to our production instance. I'm using eclipse as my IDE is their anyway to bypass the unrelated errors without having to fix / un-install the 3rd party code?

Long Version:

To set the scene its been a while since we have done any development on our own instance. Today I went to make a small change to one of our triggers (Adding a new condition to an IF statement).

For reference this is the trigger (Created as part of our Email2Case Premium):

trigger AssignAccounts on Case (before insert) {

    List<Account> acc = [SELECT id FROM Account WHERE name = '<Our Client Name>'];

    if (acc.size() == 1){
            for(Case c : trigger.new){
                 if (c.Origin == '<Our Client Name> Support - Email' || 
                     c.Origin == '<Our Client Name> Support - Phone'){
                    c.AccountId = acc.get(0).id;
            }
        }
}

However when I tried to 'Save to Server' in Eclipse I got a list of test failures all unrelated to the change I was making. These failures occurred in 2 Unmanaged packages our project manager has installed, Milestones PM (Over a year ago) and Time Off Manager (2 months ago).

Description Resource    Path    Location    Type
System.AssertException: Assertion Failed    Milestone1_Charts_GanttController.cls   /our_instance/src/classes   line 134    Force.com run test failure
System.DmlException: Insert failed. First exception on row 0; first error: CANNOT_INSERT_UPDATE_ACTIVATE_ENTITY, Milestone1_Milestone_Trigger: execution of AfterUpdate
caused by: System.LimitException: Too many SOQL queries: 101
Class.Milestone1_Milestone_Trigger_Utility.updateProjects: line 310, column 1
Class.Milestone1_Milestone_Trigger_Utility.updateParents: line 264, column 1
Class.Milestone1_Milestone_Trigger_Utility.handleMilestoneAfterTrigger: line 231, column 1
Trigger.Milestone1_Milestone_Trigger: line 22, column 1: [] Milestone1_XML_Import_Utility_Test.cls  /our_instance/src/classes   line 41 Force.com run test failure
System.DmlException: Insert failed. First exception on row 0; first error: FIELD_CUSTOM_VALIDATION_EXCEPTION, Maximum per user chatter subscription limit has been exceeded: [] Milestone1_Task_Chatter_Tst.cls /our_instance/src/classes   line 60 Force.com run test failure
System.DmlException: Update failed. First exception on row 0 with id a0RD0000005B4YpMAK; first error: TRANSFER_REQUIRES_READ, The new owner must have read permission: []   tom_test_cancellation.cls   /our_instance/src/classes   line 37 Force.com run test failure
System.DmlException: Update failed. First exception on row 0 with id a0RD0000005B4Z7MAK; first error: TRANSFER_REQUIRES_READ, The new owner must have read permission: []   tom_test_status_changes.cls /our_instance/src/classes   line 96 Force.com run test failure
System.LimitException: Too many SOQL queries: 101   Milestone1_Test_Move.cls    /our_instance/src/classes   line 306    Force.com run test failure
System.QueryException: List has more than 1 row for assignment to SObject   tom_test_error_conditions.cls   /our_instance/src/classes   line 11 Force.com run test failure

So my question comes down to, Is there a way I can make my changes without having to fix this 3rd party code or un-install them? Having a look at the errors it may be possible to fix the Assertion Errors but the rest will mean going through the entire package.

Also I would be interested if anyone can tell me how these packages managed to get installed in the first place if their unit tests failed?

  • 1
    To second the questioner, I just got a ton of failures in the Time off Manager unmanaged package spontaneously after winter '13. Just wanted to chime in on this thread since the focus is on validation rules and org changes breaking these tests, when based on my perspective this is clearly a platform change that is breaking the tests. Something which is a big no-no in my opinion. Sorry this should be a comment, but I'm new to this stackexchange and don't have enough rep yet. – Ralph Callaway Sep 23 '12 at 19:32
4

Jon,

It was previously possible to install managed packages and Ignore APEX Test Errors this isn't the case anymore.

Your probably going to have to uninstall them if you want to deploy from Sandbox to production, and reinstall them.

If it's Milestones PM (the package) is you can probably get an unmanaged version to work with and fix the bugs.

UPDATE

Looks like you are using the unmanaged package. So I think if you don't want to uninstall before going to production your going to have to fix those errors manually by fixing the code.

Unfortunately, SFDC test methods don't live in a complete vacuum where you can run tests against your org without bumping other code, even when you go to deploy.

  • The other two problem causers I've seen are (1) You have validation rules, required fields, etc. that were added to Objects used by the tests after installation. For example, their tests could "mock" an Account and insert it and everything is fine...then you come along and add a new custom field that is required causing all of their unit tests to fail. (2) The unit tests depend on certain data in actual DB and you alter that data or delete it. In both of these cases the packages would have installed w/o error. – Peter Knolle Sep 5 '12 at 17:34
  • 5
    I wanted to point out that test classes that come as part of managed packages are not run on code deployments - regardless of the "Ignore Apex Test Failures" setting (that no longer exists) or @isTest(onInstall=true) annotations. As such they never fail, so managed classes are never a factor in deployment unless your deploy call explicitly requests run all tests. See: salesforce.com/us/developer/docs/api_meta/Content/… – ca_peterson Sep 5 '12 at 18:07
  • 1
    Jordan, you're incorrect about not being able to ignore test failures with managed packages. They are now ignored by default when deploying code to production via all standard methods (Change Sets, Force.com IDE and Force.com Migration Tool). See my post in the apex developer forum and the answer from Josh Kaplan (the Product Manager for Apex) here: boards.developerforce.com/t5/Apex-Code-Development/… - note that he says specifically unit tests for managed packages are not run during deployment by default. – E.J. Wilburn Sep 5 '12 at 19:01
  • 1
    Ah, ca_peterson said the same thing. Responded to Jordan's post before reading that. I get a little, um, excited when I see/hear people stating that managed package unit test failures prevent deployment as I've had lots of trouble convincing customers that this is not the case. – E.J. Wilburn Sep 5 '12 at 19:03
4

Unfortunately your only options with an unmanaged package are to either fix the offending code and/or unit tests or uninstall the package.

There might be a quick fix available though. If you edit the Apex classes in the package and change their API version to 24.0 or greater that will run the unit tests without giving them access to your data, which is possibly what is causing the exceptions you're receiving. The unit tests (or package itself) might not have been designed to work properly with the volume of data you have in your Salesforce instance.

As to how the package got installed in the first place, there are a couple of possibilities. First, unit tests do not have to be run on installation anymore depending on how the package is configured. Second, it used to be possible to ignore unit test failures during package installation.

  • This sounds promising, I will try it out and let you know :) – Jon Hazan Sep 6 '12 at 10:26
  • Just to keep you up to date, I have tried setting the API version directly in the meta xml files. However there are some small issues around this that I will try to fix before ruling my final answer :) – Jon Hazan Sep 7 '12 at 16:12
  • In the end I was unable to get this to work as I couldn't save the changes to the meta xml's back to the server... Thanks for the help tho :) – Jon Hazan Sep 20 '12 at 12:25
  • You'd have to make the change in a sandbox or developer org and then deploy those changes to your production org. Using a change set would probably be the easiest method. – E.J. Wilburn Sep 20 '12 at 18:25
2

Jon,

The last line of the output you provided shows: "tom_test_error_conditions.cls ... line 11 Force.com run test failure" That's not a class in my Milestones.PM unmanaged package. Is it possible a trigger in some other code in your org is being executed by the Milestones.PM operations and that class is where the error actually is?

Also, I see the following in your output: Maximum per user chatter subscription limit has been exceeded: [] Milestone1_Task_Chatter_Tst.cls /our_instance/src/classes line 60 Force.com run test failure

That failure is probably due to the running test user's chatter following limit. Not directly an issue with MilestonesPM.

In net, maybe there are other environmental issue that aren't in MilestonePM that need to be addressed. And in answer to your last question, those environmental issues likely weren't the case when you first installed MikestonePM.

  • The tom_test_error_conditions.cls is a separate package and is throwing its own errors. Good point about the other triggers interfering. – Jon Hazan Sep 6 '12 at 10:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.