I'm running unit tests in Eclipse (Force.com IDE) and they are taking 5min+ to execute. Is there an alternative way to run them, or are there tips to speeding this up? I know I can run the tests from the setup menu GUI, but it doesn't seem to give the same detailed messages and debug logs as the IDE.
If you run your tests from the setup menu GUI, you should be able to get the same logs as via Force.com IDE if you have Developer Console open whilst you run your tests. See this post for info about using Developer Console for logging:
I do find this method quicker than waiting for the IDE but I always get frustrated trying to edit code in the browser.
To see which lines were/were not tested see the 'Overall Code Coverage' panel on the top right, double click the class you're interested in and you'll see the output below:
For my use case setting the Log-Level to WARN or ERROR as increased the speed from about 2 minutes to only 3 seconds. In works in Developer Console as well as in eclipse. However finding the right settings in eclipse, caused me some hick-ups:
This will not speed up or can be used for all possible use cases. But it's worth a try!
I'd second the other answers in trying other methods of executing the unit tests outside of Eclipse. Also, explore if the test cases are just slow by their nature or quantity.
I don't know why, but sometimes Eclipse just seems to hang when running unit tests for me (and often when saving files). It's like the test has finished running in Salesforce ages ago but there is a significant delay before Eclipse picks up that is has completed and displays the results.
It got so bad that I had time to build my own tool to run the test cases using the Salesforce APIs. You can get the FuseIT SFDC Explorer for free (Windows only at this stage).
Once you have logged in go to Apex Tests tab in the bottom left. Then enter a filter for the classes you want to test and hit Search. The checked test classes than then be run either synchronously or asynchronously.
Changing the Logging Levels to Warn, Error, or None can greatly reduce the size of the log file that gets created and displayed.
I'm still tinkering with it, but hopefully it is helpful if Eclipse is slowing you down in the testing department.
I noticed recently that there is a Force.com IDE Log Viewer in Eclipse (Help > Show Force.com IDE Log). It might provide some more clues as the why the IDE is hanging.
I don't necessarily have a good way to speed up unit tests, but I would like to quickly share an article a co-worker of mine found that my company has used to set up scheduled unit test runs nightly.
We took this article as inspiration and tweaked it rather significantly, but the end goal was getting unit tests running nightly. The reason for this is that on the scale of some of our projects, a full unit test run through takes upwards of 40 minutes. The ridiculous amount of data model that needs to be built really hinders some of the things we have tried to do. Some of our unit tests require up to 50 unique object types to be built up. This causes significant performance issues and thus increases time the unit tests run. Allowing these unit tests to run as a whole at night allows the developers to not run all of the unit tests constantly (although this is NOT ideal in true TDD). Unfortunately, time constraints are a reality on many projects.
I would suggest setting this up in your development environment but also set it up in production orgs as well. Being able to see if an administrative change (such as adding new required field validation) will break your unit tests every night is invaluable and saves time when it comes closer to deploy.
I put together a simple java sample which shows you how to write your own test runner from the command line. I've used it when the IDE locks up.
5 minutes is not a lot, relative to the number of Test Classes you are running.
It might be an idea to look through the debug logs (for time stamps) or even trying to run culprit tests that you think might be hogging the time, individually, to isolate the performance hoggers.
Some common sense best practices would be to externalise creation of setup test data to a reusable method in a utility class, and structure tests such that you are justifying the cost of creates with sufficient assert statements and grouping related asserts together rather than recreating data each time.
If however the test times are down to the sheer processing, then it would be harder to optimise run times. A few ideas
Use Test.isRunningTest to check if a test is running and use that switch to make any performance optimisations that you think you can afford, for eg. A mock response if that isn't subverting the unit test
Do not use SeeAllData=true and create your own test data. This is particularly relevant to classes which may be firing soql queries and processing data. They should only be processing data inserted in the test rather than any static data in your sandbox.