Developer Console Winter 14 anomalies
OK, SFDC Support provided the workaround
Test Run creates an entry in the Tests tab labeled Test @Invalid Date.
Once I run a test of an Apex class, clicking Test Re-Run does not actually launch a repeat of the previous test (at least no new test entry appears in the Tests tab. Manually re-selecting the class does not run it either (at least as far as the Test tab is concerned)
- Logs don't always appear (or rarely appear) from any tests run through the developer console; setting is 'Show My Current Logs only'
- Debug | Resume does nothing; no refresh of any tests or logs
Issues 2-4 can be worked around by doing the following sequence:
- Test | New Run | select class(es)
- Test tab shows test running, test completes, Logs tab shows test log
- In the Test tab, double click the class that you ran (say, class 'Foo'). This opens a tab at the top of your workspace for that Test run with all classes ran in that test. You can see method-by-method test results.
- Test | Re-run - will execute the tests in the classes appearing in the tab from step 3
Essentially, the Developer Console 'forgot' the test classes you selected in step 1 so when you click Test | Re-run, there is nothing to re-run. By double clicking your test results, Developer Console's "memory" is jogged and it is now ready to execute your Test | Re-run.
Developer Support noted that many Dev Console issues should be fixed 'real soon'. Hopefully this will include Issue 1 which is a Firefox issue only as well as an intuitive fix for issues 2-4.
Thanks for the info on #1. I filed a bug for the FF date issue.
I'm not aware of #2, but will look into it.
In terms of #3 and #4, the Developer Console has moved over to system streaming topics for logs, tests, and container deploy requests in Winter '14. In other words, instead of polling every 3 seconds to look for logs (and other stuff), we now rely on the streaming API to let us know when logs are created or certain changes happen.
If I had to guess, I would imagine that this is where the issue lies. I'm curious where the bottleneck is. The first thing to do is to see if there is a javascript error related to "cometd", which is the streaming API. If so, please file a case.
If you are receiving "cometd" network traffic (you can easily see them in chrome's network tab or FF web console tab) but the logs are still not being retrieved unless the dev console is refreshed, then there is a delay in the streaming API sending them to the dev console. In that case, you should probably also file a case.
If you do file a case, please let me the case #.