To run a test, use any of the following:
All Apex tests that are started from the Salesforce user interface (including the Developer Console) run asynchronously and in parallel. Apex test classes are placed in the Apex job queue for execution. The maximum number of test classes that you can run per 24-hour period is the greater of 500 or 10 multiplied by the number of test classes in the organization. For sandbox and Developer Edition organizations, this limit is higher and is the greater of 500 or 20 multiplied by the number of test classes in the organization.
After you run tests using the Apex Test Execution page, you can view code coverage details in the Developer Console.
From Setup, enter Apex in the Quick Find box, select Apex Test Execution, then click View Test History to view all test results for your organization, not just tests that you have run. Test results are retained for 30 days after they finish running, unless cleared.
In addition, you can execute tests with the Force.com IDE (see https://developer.salesforce.com/page/Apex_Toolkit_for_Eclipse).
The Developer Console enables you to create test runs to execute tests in specific test classes, or to run all tests. The Developer Console runs tests asynchronously in the background allowing you to work in other areas of the Developer Console while tests are running. Once the tests finish execution, you can inspect the test results in the Developer Console. Also, you can inspect the overall code coverage for classes covered by the tests.
For more details, check out the Developer Console documentation in the Salesforce online help.
RunTestsResult[] runTests(RunTestsRequest ri)
For more information on runTests(), see the WSDL located at https://your_salesforce_server/services/wsdl/apex, where your_salesforce_server is equivalent to the server on which your organization is located, such as na1.salesforce.com.
Though administrators in a Salesforce production organization cannot make changes to Apex code using the Salesforce user interface, it is still important to use runTests() to verify that the existing unit tests run to completion after a change is made, such as adding a unique constraint to an existing field. Salesforce production organizations must use the compileAndTest SOAP API call to make changes to Apex code. For more information, see Deploying Apex.
For more information on runTests(), see SOAP API and SOAP Headers for Apex.
You can also run tests using the Tooling REST API. Use the /runTestsAsynchronous/ and /runTestsSynchronous/ endpoints to run tests asynchronously or synchronously. For usage details, see “REST Resources” in the Force.com Tooling API Developer’s Guide
You can run tests asynchronously using ApexTestQueueItem and ApexTestResult. Using these objects and Apex code to insert and query the objects, you can add tests to the Apex job queue for execution and check the results of completed test runs. This enables you to not only start tests asynchronously but also schedule your tests to execute at specific times by using the Apex scheduler. See Apex Scheduler for more information.
To start an asynchronous execution of unit tests and check their results, use these objects:
Insert an ApexTestQueueItem object to place its corresponding Apex class in the Apex job queue for execution. The Apex job executes the test methods in the class. After the job executes, ApexTestResult contains the result for each single test method executed as part of the test.
To abort a class that is in the Apex job queue, perform an update operation on the ApexTestQueueItem object and set its Status field to Aborted.
If you insert multiple Apex test queue items in a single bulk operation, the queue items will share the same parent job. This means that a test run can consist of the execution of the tests of several classes if all the test queue items are inserted in the same bulk operation.
The maximum number of test queue items, and hence classes, that you can insert in the Apex job queue is the greater of 500 or 10 multiplied by the number of test classes in the organization. For sandbox and Developer Edition organizations, this limit is higher and is the greater of 500 or 20 multiplied by the number of test classes in the organization.
public class TestUtil { // Enqueue all classes ending in "Test". public static ID enqueueTests() { ApexClass[] testClasses = [SELECT Id FROM ApexClass WHERE Name LIKE '%Test']; if (testClasses.size() > 0) { ApexTestQueueItem[] queueItems = new List<ApexTestQueueItem>(); for (ApexClass cls : testClasses) { queueItems.add(new ApexTestQueueItem(ApexClassId=cls.Id)); } insert queueItems; // Get the job ID of the first queue item returned. ApexTestQueueItem item = [SELECT ParentJobId FROM ApexTestQueueItem WHERE Id=:queueItems[0].Id LIMIT 1]; return item.parentjobid; } return null; } // Get the status and pass rate for each class // whose tests were run by the job. // that correspond to the specified job ID. public static void checkClassStatus(ID jobId) { ApexTestQueueItem[] items = [SELECT ApexClass.Name, Status, ExtendedStatus FROM ApexTestQueueItem WHERE ParentJobId=:jobId]; for (ApexTestQueueItem item : items) { String extStatus = item.extendedstatus == null ? '' : item.extendedStatus; System.debug(item.ApexClass.Name + ': ' + item.Status + extStatus); } } // Get the result for each test method that was executed. public static void checkMethodStatus(ID jobId) { ApexTestResult[] results = [SELECT Outcome, ApexClass.Name, MethodName, Message, StackTrace FROM ApexTestResult WHERE AsyncApexJobId=:jobId]; for (ApexTestResult atr : results) { System.debug(atr.ApexClass.Name + '.' + atr.MethodName + ': ' + atr.Outcome); if (atr.message != null) { System.debug(atr.Message + '\n at ' + atr.StackTrace); } } } }