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
rlt9999rlt9999 

Run Test button always fails

Recently I started geting an error trying to run any test code. This includes tests that have not been modified since 2009.

I choose any of my classes and click Run Test or click Run All Tests from the class list screen and I get this error message:

 

line -1, column -1: Method 'invoke' exceeds the maximum number of allowed op codes. Please break this method into multiple, smaller methods.

 

This happens in my production instance and 3 of my 4 sandboxes. However it works properly in 1 of my sandbox and a developer account.

 

Has anyone else seen this? Any ideas?

 

Salesforce is rejecting my support cases because my maintenance does not cover developer issues even though I insist this is NOT a developer issue.

 

Thanks.

Best Answer chosen by Admin (Salesforce Developers) 
rlt9999rlt9999

Ok. I found the problem.

 

Back in July a contractor was brought in and he had created a trigger with a large amount of code. The project was unsuccessful and he was let go but the code was left in place.

 

It didnt cause any problems until just the last few weeks when I guess the Spring '12 no longer tolerated it.

 

I found it by comparing the sandbox that work with the one that didn't.

 

 

All Answers

Navatar_DbSupNavatar_DbSup

Hi,

 

I have also faced same problem. I have divided my method into two different methods now my code working fine. So I suggest you to divide your method into multiple methods and then run your test method.

 

For more detail follow the below link:

 

http://boards.developerforce.com/t5/Apex-Code-Development/Method-CodeCoverage-exceeds-the-maximum-number-of-allowed-op/td-p/399829

 

http://boards.developerforce.com/t5/Apex-Code-Development/Compile-Error-Method-exceeds-maximum-number-of-allowed-op-codes/td-p/343135

 

Did this answer your question? If not, let me know what didn't work, or if so, please mark it solved. 

 

 

rlt9999rlt9999

Thanks for the quick reply.

 

In one case the entire test method is only 14 lines long. I really do not think the error message is valid.

This happens on all test methods even those that worked a few weeks ago and have not changed.

 

craigmhcraigmh

It's not the test method itself that is too long, it's the method that your test method is testing.

rlt9999rlt9999

The test code is testing a method that contains only 34 lines of code.

This same test worked fine a few weeks ago and an exact copy works correctly in at least 2 other Salesforce instances.

 

Thanks, but it appears to be failing for some other reason.

 

 

rlt9999rlt9999

Here's another clue to this mystery (hopefully):

 

Even though the test method fails the code coverage is calculated and the document highlighting each line that was covered is created.

I am not sure what this means but I am running out of ideas.

 

craigmhcraigmh

Sounds like SFDC needs to fix their error message.

rlt9999rlt9999

Another clue:

 

I get the same error when attempting to install ANY app from AppExchange.

I tried this because I think it is somehow related to running test code in my instance which of course is done when an app is installed.

 

I submitted this as a new support case to Salesforce but it was rejected as well.

 

Anyone have any suggestions on how I can convince Salesforce that this is their bug?

 

 

craigmhcraigmh

When you push a changeset to or install an app on production, ALL of the test methods from all modules are run. So even if you tried to push a trigger with one line, it would fail.

 

I don't remember seeing this issue before Spring '12, so it wouldn't surprise me if SFDC was the cause. I'm surprised that they rejected the bug, when it seems to be their issue.

rlt9999rlt9999

Ok. I found the problem.

 

Back in July a contractor was brought in and he had created a trigger with a large amount of code. The project was unsuccessful and he was let go but the code was left in place.

 

It didnt cause any problems until just the last few weeks when I guess the Spring '12 no longer tolerated it.

 

I found it by comparing the sandbox that work with the one that didn't.

 

 

This was selected as the best answer