Apex Code Development You need to sign in to do that
Don't have an account?
TLF Running unit tests in Force.com IDE seems to be taking much longer
I recently upgraded my Force.com IDE (and all projects) to the Winter '12 release. Since upgrading, I've been observing that when I attempt to run unit tests against an Apex class, it often takes a very long time to execute. Even relatively simple tests sometimes take a minute or two to complete. The time doesn't seem to be spent during test execution, but rather during the "preparing results..." phase (based on the progress indicator in the IDE). Reducing the log level doesn't seem to have any impact one way or the other. I've also seen it simply get stuck in the "preparing results..." phase to the point where I had to kill the Eclipse process. Anyone else seeing this?
I too upgraded to the Winter '12 version of the IDE last week - I concur with you...my actual deployments are still running at the same pace as before, but the post-processing is taking forever. I haven't had to force-quit out though.
-Andy
Sampling eclipse while the tests are running shows that it's spending a lot of time in the MetadataDebuggingInfoHandler.characters method. This is true even when all logging levels are set to 'none'.
Also, the post-processing seems to get slower the more test runs are done before restarting Eclipse.
This is also a problem in the branded Force.com IDE.
cheers
Rohan
Further experiments seem to indicate that the web system log is overriding or changing the logging levels seen by eclipse. When I take the 'system' logging level (which is not configuable in eclipse) back to info or higher then the eclipse test run with no logging runs fast. Unfortunately turning logging back on in eclipse drops performance again.
cheers
Rohan
I am having the same issue. Happens on Mac and Windows. I even upgraded to the latest version of the Force.com plugin 23.0.2.201201091635 that was released just the other day. I guess it doesn't address this issue. I don't even run tests in the ide anymore, have to go to the browser.
Same issue here with 23.0.2 on PC and Mac. Testing in Eclipse is basically unusable for all but the most basic code. Has anyone opened a case?
is there any word on this? This is seriously killing my dev cycle. It's taking upwards of 5-7 minutes to save one file when I make changes against the prod org.
This is seriously not okay. Any work arounds would also be appreciated.
I have not opened a case against this. I don't think this would be covered under "basic" support, but would in fact be a developer support issue and I don't have a paid developer support subscription. I have basically given up on trying to run unit tests within the IDE. I now run unit tests pretty much exclusively via the "Apex Test Execution" page. This actually has the benefit of being asynchronous. You can start the tests running in the background while you continue to use the IDE to edit your code.
is there a way to make eclipse skip the tests?
When i try to push into the production org I almost can't now because it takes so long to run the tests through eclipse, but the changes I want to make can't be done through the UI (or at least I don't see the same options to create new classes and triggers).
This is becomming maddening because I've been sitting here for 30 minutes and effectively gotten nowhere with this IDE.
If there is an option to turn on creating of apex triggers/classes through the UI in the production org, please let me know. Eclipse is really bugging the crap out of me!!
Or a way to get eclipse running up to speed again lol
You are essentially performing a full DEPLOY when you are actively developing in a Production org, and there is no way around turning off Unit Tests or anything of that sort when doing this.
As a matter of "best practices" - why not spin up a Sandbox and develop in there? If you're coding Apex, you have an org that can at minimum spin up a Developer Sandbox...
-Andy
That's what i am trying to do. Take my code from sandbox, and push it into production. It's taking FOREVER and is killing our ability to effectively do things.
What a terrible design.
Actually, it sounds like what you are describing is slow deployment to production. This is not the issue I originally was reporting on. I haven't actually seen a change/increase in deployment time. My complaint is against running unit tests within my Developer Edition org. Long deployment times could be due to the fact that you have a lot of custom code and/or third party managed packages already installed in production. When you try to deploy from a sandbox or DE to production, it runs ALL unit tests currently in production during the deployment, not just the unit tests in the Apex code you are deploying. This could be what is leading to your 5-7 minute deployment times. I'm not really sure if there are any workarounds for this, other than doing all your development and testing in the DE or developer sandbox and only deploying once you are sure everything is working in your development environment.
Aaahhh! Doh! My bad - I misread your initial message. I thought you were actively developing in Production.
Yeah, about a month ago Eclipse's deploy speed just TANKED. If you actually watch your deployment happen in your target org, that part actually takes the same amount of time as you'd expect...it's Eclipse ITSELF that now is taking so darn long to come back.
I have an org with 87 unit tests (incredible amount of code) and Eclipse takes about 30 mins to do it's thing. Watching the Deployment Status in my prod org - the deploy reports as successful within 10 minutes. That's 20 minutes of Eclipse just farting around.
THAT situation I agree with you in absolutely horrid. Don't know what changed, but it needs to get fixed.
Gah it's a two fold issue - the super long deployment time = wow this is lame.
The running of unit tests from eclipse = wow this is lame.
I'm backing up against the former now as I have corrected the unit tests ;)
I have logged a case with developer support. We will see what they say.
If you feel the slow deployment is definitely due to the Force.com IDE, can you deploy using change sets instead?
@Salesforce.com: This is really serious. Right now I am still waiting more than 15min for Eclipse to prepare the results of my 10 testclasses. A thing which took 30seconds in the Browser.
Please open source the IDE even faster.........
What is the update on this? Any word from Salesforce Support?
For us, using Force IDE in Eclipse, it takes about 1 hour now to deploy anything to Production, that is up from about 15 mins a couple of months ago.
To simply test certain classes while using Sandbox in Eclipse, takes the same amount of time as in SF UI, which is usually under 20 seconds, but it gets stuck on the "Preparing Results" stage, and Eclipse just sits there for 20 mins or so, frozen, doing god knows what.
Same problem here. It takes a looong time to deploy anything to production. The problem started after the last upgrade of Force.com IDE.
6 months???? This thread is going to be 6 months old shortly and not a word??? really?
The ANT Deploy scripts work wonderfully and that is what I use to deploy now. You still get the test results, just not in the fancy IDE - it's all dumped to the console as part of the ANT Deploy.
I think the ANT deploy is the proper way to handle it anyways, for pushes to production at least, though being able to make use of the Eclipse IDE tools is also nice ;) so i hope this gets some love soon.
Thanks Mike. I have not experience with the ANT deploy scripts. I've done all my coding in the IDE. Maybe I'll have to take a look at that...
It just seems odd that SF hasn't responded to this...
Thanks again.
Yeah with little effort you can script up nice deploy pieces that can dynamically build and package your code up into package.xml files and test/deploy your code into production.
I have a lot of SFDC instances to work with so it's nice to have a central place that can push to and from all of my various SFDC instances with a single piece of code. The only caveat is that you have to...well build it yourself lol.
You can build/run it all from eclipse though - and I would definitely recommend that over running ant on the command line. Eclipse can parse Ant dialogs and easily locate errors...etc that may arise.
Interestingly, IDE actually deploys stuff relatively quickly, but then it gets stuck in the "results preparation" stage, while locking up the Eclipse.
You can use SF UI to deploy your stuff, that functionality is working fine, still. Takes about 15 mins to deploy in our org.
http://login.salesforce.com/help/doc/en/changesets_about_outbound.htm
I have realized that it takes longer for the IDE to deploy on a slow computer, I have seen that it starts taking up 100% CPU as soon as it enters the "preparing results" stage. I guess a super computer would make deployments happen much faster, if only I had one I would have saved many hours.
I'm not sure why the above response was marked as a solution. The original post was asking about running unit tests, not deployments. And getting a super computer is a bit of a sarcastic solution; although I feel your pain.
I have noticed that running tests in Eclipse has taken an extraoradinarily long time compared to several months ago. I just did a few "tests" in a very simple test class that creates a list of leads and converts them. When my list of leads is only 1, the test runs in about 8 seconds. I tried it for the following list sizes with increasing wait times:
1 leads -> 8 seconds
10 leads -> 28 seconds
20 leads -> 90 seconds
200 leads -> 191 seconds
SFDC recommends to use at least 20 records in your unit tests. I like (or at least used to like) to use 200. I think the recommendation came from the fact that you used to only be allowed 20 SOQL queries per trigger and they wanted to make sure the triggers were bulked. Now that governor limit is 100 so I would think we should create 100 records minimum to test triggers.
This has got to be fixed. When I run the same test class in the GUI, it still takes over 2 minutes. And, my class that had 100% coverage in Eclipse only shows 43% in the GUI. I don't know if this can be attributed to an issue in Eclipse or just some new bugs introduced in the last few versions.
SFDC: if you want us to write good test coverage, we should be able to trust the results whether we use the GUI or Eclipse AND we shouldn't grow old waiting for the results!
George Sowards
www.RedPointSolutions.com
@geosow Unit tests always get executed as part of the deployment from sandbox to production, that's how the 75% code coverage is checked for before the actual deployment takes place.
When running unit tests separately I use their new GUI (under Setup | Develop | Apex Test Execution) which is indeed faster than IDE plus I like the feature where they highlight lines of code that did not get coverage.
I too have found differences in code coverage but I have never paid much attention at the total code coverage, I look at the code coverage of each class separately in a test result.
I clearly noticed improvement in wait times after moving to a faster CPU (from AMD 3600+ to Intel E7500), maybe you can give it a try and prove me wrong. But either way, their IDE needs to be improved.
thats strange, bc the processor speed should not matter since all testing is done on SF server. The only thing your processor would be doing is going over the results and putting them on your screen. Maybe thats the part SF miscoded in the last release
If the processor makes a difference, it means its a problem with the IDE. The time for tests to run in older versions was much shorter, and upgrading the IDE should not require a major hardware upgrade as well.
Just wanted to chime in that this is a major issue for our enterprise org right now... ~750 tests being run each deployment.
@cmendler: I do feel your pain and I'm sure increasing your CPU power would not help as some are suggesting on this thread. I work with one client that takes about 45 minutes just to create a project in Eclipse now and about that long to deploy just a single line of new code. That issue popped up for me around the Summer '11 release. I really think the issue needs to be addressed or at least acknowledged by Salesforce who are absent on this thread unfortunately.
However, and why I'm replying, I remember in a webinar from Salesforce called "deep dive into the developer console" the presenter mentioned your issue and that they are hoping to allow deployments without running every single test. Does anyone know how to find that webinar recording? He had no other information on when they were looking to release. But at least that issue should be addressed in the near future of requiring all tests to run just to deploy one class or a change to a trigger.
Found the webinar I mentioned above: http://wiki.developerforce.com/page/Webinar:_DevConsole
Go to 30:30 and listen to what Taggart says: "...we want to be smart about this..." The feature is called "smart deploy" and was slated for Summer '12. They covered their liability with a safe harbor statement in this portion though.
I didn't hear anything about "Smart Deploy" in Summer '12. So until "Smart Deploy" is released, we're working with a "Stupid Deploy" (for lack of a better more politcally correct term)....
@geosow
Heck, I nice first step would be for All Tests not to run when deploying something extremely simple and not functionality-related (like a Report).... that is just ridiculously excessive.
I haven't seen the webinar you are speaking of, but it would be fantastic to have that feature. We actually have devs that have developed (beta) a change control, release management, and DEPLOYMENT platform for SFDC that we plan to replace the IDE, Change Sets, and ANT migration tools with. Look out for that presentation on the web after it is presented at Dreamforce this year.
I will never get back the hours I have wasted over the past weeks waiting for Eclipse to build. Our project is now completely locked up.
I hope this helps some people.
I enabled logging on my account before I did a build from Eclipse.
I found that the actual server time was usually a second or two, even when the build took minutes on Eclipse. Fiddler verified that the response from SF was very fast.
I replaced the builder task in Eclipse with ANT.
I changed the default settings to NOT build when I save.
Now, I can save documents and then when I am ready, I hit ctrl+B and Ant kicks off. The build is faster and the comments are more verbose and meaningful.
Tom666,
Can you tell us more about your approach? It sounds like this primarily helps to alleviate the long running, or stalled compilation operations. Does it also help with the unit test issue? Do you use ANT to run your unit tests? How do you "replace the builder task in Eclipse with ANT"?
Would be interested in this also, now it is really painfull to run the tests. For now I use my browser next to eclipse, to run the tests, but not really happy with that approach.
The slowness in eclipse has been driving me insane the last several months. For both running tests and doing deployments to production within eclipse, the actual action takes the typical time, but the "preparing results" crap locks up eclipse for potentially 10 minutes or more after everything is actually completed. It's not quite as bad on my crazy-upgraded gaming PC at home, but it's still unacceptable in my opinion.
SALESFORCE... WHEN IS THIS GONNA BE FIXED?
I have the equivalent of a desktop supercomputer (Quad core, 16 GB RAM, etc.), and it is doing it..I am very interested myself in what changed, as running tests in the IDE is now horrible.
It appears that at long last this has been fixed. I just upgraded to Winter 13 / v26 and running tests or deploying no longer stalls on "Preparing Results". Tests now take the same amount of time to run as in the Web UI.
Thats great but I don't see this mentioned in their release notes (http://wiki.developerforce.com/page/Force.com_IDE_Release_Notes).
Can anyone else confirm?
Honestly, I don't see any improvement in version 26. It still took a couple of minutes longer to run the tests for a single class in the IDE, vs. in the Salesforce UI, and most of that time was still spent "preparing results". I also had it hang completely running tests once, and I had to kill the eclipse process.
YEP, THEY FIXED IT. I JUST UPGRADED THE IDE, RAN A TEST, AND IT WAS AS SNAPPY AS BEFORE. ONLY TOOK MAYBE 20 SECONDS TO SEE THE RESULTS.
I USE MYECLIPSE WITH A FORCE.COM IDE ADD-ON.
It's not that great for me after the upgrade. Now it takes 2 minutes 30s to run 73 tests and complete the deployment, but then Force.com IDE is still blocked for another 5 minutes running one of the processor cores at 100%.
It seems to be a bit quicker after the upgrade to Winter '13, but the problem is still there.
This is still a big deal. Why do I (and other developers) often have to wait 10+ minutes while Eclipse is "preparing results" from a test class that took maybe ten seconds to run.
Console now during development ? it?s faster and the Summer ?13 features
look even better. But to validate or deploy from Eclipse, grab a cup of
coffee?.and wait?..
*--*
George Sowards
*. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . *
Salesforce.com Certified Advanced Developer
*RedPoint Solutions, Inc.*
Toll-free: *(855) CRM-FIRM*
Direct: (303) 847-0846 x101
profile: linkedin.com/in/georgesowards
email: george@redpointsolutions.com
*Celebrating over 10 years of "Putting the force in your sales force?*
and wait... and wait... and wait...
Do you suppose this is intentionally being left out in an effort to get us to move to the console????
Can you elaborate on how you are using the console to run your unit tests?
The developer console. There was a good webinar about it this month. A portion discussed details not out until Summer '13 but it will show you how to run all tests or a single test using the developer console: http://wiki.developerforce.com/page/Webinar:_Advanced_Testing_%26_Debugging_Using_the_Developer_Console_(2013-Apr)
In my personal opinion, I don't think anyone is purposely not working on the IDE to get us to us the GUI. I just think it's a a different team that works on both...
Does anybody know if that operation can be moved to background somehow, and not lock the IDE?