First of all, I’m happy to see you. If you’re reading this, it means you have written Apex tests and want to run them, which makes me very happy. I’ll explain why in a later blog post, but for now, just know that writing and running tests is good for you AND good for us.
Now to the topic of the hour: Where did my old test result UI go?
You may have noticed that, with the Spring ’13 release, the “Run All Tests” button on the Apex Classes list view page and the “Run Test” button on an Apex class detail page now take you to a different place. We have retired the old test running UI.
Why did we retire the old test user interface?
The old behavior behind those button was to synchronously run your tests, and that was bad. If you have a small number of tests, you probably did not know that it was bad. If you have a large number of tests (and you should!), you likely figured out that running the tests from these buttons could be problematic.
Synchronous test runs have to complete the entire run before the user can interact with the system or the results. There was no way to interrupt a test run; closing the browser window did not stop the execution process. If your tests take a long time to run, that meant waiting a long time to be able to start again.
The results of a synchronous run were only available to the browser session that kicked it off. If the browser died for any reason, there was no way to get the results of that run. Imagine if you had waited an hour for your tests to run, and your daughter decided it would be a good time to use your unattended computer to watch Dora clips…you now had to start all over again to see the results, and probably not until after Dora was done. There was no way to share the results of the run with anyone. And if you clicked a class name, the browser redirected to that class, and if you hit the back button, you ran all tests again!
For tests which do not create their own data, synchronous test could be even more problematic. If a test utilized org data and modified it, that record is locked throughout the run of that test method, until the rollback occurs. (This is still true to a different extent in asynchronous tests – please don’t rely on org data for your tests!)
Bearing all that in mind, we’re retiring the synchronous test running user interface. All tests that you run in the user interface are now run asynchronously. All of the bad things mentioned above are no longer an issue!
Where did my results go?
They’ve gone to a better place. Places, to be exact: the Apex Test Execution Page and the Developer Console. The things that the old UI did show you are now available in both the Developer Console and the other setup UI pages.
Results in the Setup UI Pages
View Results: The immediate action of the Run Tests and Run All Tests buttons is to redirect to the Apex Test Execution page, where you can see the results of your tests. Selecting a test will show the results, duration, and any error messages on the screen. You can see prior test runs to compare results.
Code Coverage: To see the coverage results, you can click over to the Apex Classes or Apex Triggers list view pages. Inline you will see the coverage percentage, and clicking the number will bring up the familiar blue / red highlighting to show specific line coverage. This view has a drop down at the top lets you view coverage provided by each individual test – something that was lacking in the old UI!
The overall code coverage is available behind the “Estimate your organization’s code coverage” link. Keep in mind this is only accurate immediately after a Run All Tests; at other times it is an estimate, and will be incorrect based on the amount of changes you have made to your Apex codebase.
Run Tests: Back on the Apex Test Execution page, you can launch test runs directly without going to the class and clicking the old button. You can run all tests, one test, or a selected subset of tests – running a subset wasn’t possible in the old synchronous UI.
While tests are running, you can abort the running of any test. This gives you much more control over the running of tests.
Results in the Developer Console
The developer console provides all of the capabilities listed above in a single view. Test results are all on a single tab, alongside the results from prior tests runs. There’s a sidebar with the list of classes and their coverage percentage; clicking a class there opens the class editor, highlighted in the familiar blue and red on lines covered or not. There is a drop-down at the top of the class editor which lets you look at the coverage for each individual class. After a run of all tests completes, the overall code coverage is listed in the list of classes on the test tab.
You can launch tests runs from the developer console much like you can from the Apex Test Execution page. You can run all tests or some subset of test classes, abort running tests, and you can re-run a prior run so you don’t need to go re-select the same list of classes.
Where did the Download Log link go?
The Download Log link on the old test UI allowed you to get the output logs for your test runs. This is an extremely helpful artifact, especially when you have errors. Never fear! You can still access logs from tests a couple of ways.
If you launch your tests from the developer console, you have immediate access to your logs. Logs will be generated for each test, and they are displayed on the log tab. You can open each one individually, which is much simpler than trying to open the consolidated raw log and find the individual log area. The log opens in the CSI view, which lets you do more in-depth review of what happened during the test.
If you run tests using the Run All Tests button or from the Apex Test Execution page, logs will not be generated automatically. However, if you want logs made available, you can go to the Debug Logs page and set up logs for your user prior to running tests. This will generate debug logs for you, which you can access from the Debug Logs page.
In With The New!
We have tried to simultaneously provide the same functionality you are accustomed to from a user perspective, while modifying the back end in a positive way. For smaller orgs, there may not be a perceptible improvement in performance; you will have to trust me that this change removes a relic that was responsible for numerous customer cases. There were some deficiencies in the old UI that are being retired along with it. While the old UI was familiar, I hope that the Developer Console and the Apex Test Execution page will be better for you as they, too, become familiar.
Now you know more, and you are a better developer. Happy Coding!