-
Notifications
You must be signed in to change notification settings - Fork 7.6k
LiveDevelopmentMultiBrowser unit test issues #10206
Comments
CC @sebaslv |
There are also tons of non-error console status messages -- the comments near the end of the original PR (e.g. #10010 (diff)) refer to only two log statements, one of which has been removed... but the amount of stuff I see in the console is far beyond that... |
I see 73 references to |
Yeah, I know. These are two help debugging, supposedly. We will be cleaning them up. The current set of test is badly orchestrated (which causes exceptions) and, actually, not re-runnable. |
We could spin the console spam off as a separate bug if desired though. Also -- I'm not sure how LiveDevelopmentMultiBrowser causes the first issue listed above, just looking at the diff, but if I go back to before #10010 landed (e.g. commit |
Let us finish up a mail with the TODO list as we see it, we will then create more or less complete list of things (issues and stories) to track the progress of this. FWIW, if this implementation is not enabled, there's only one extra log message on the console (for a casual user). |
@peterflynn, see #10285 for the issue 1 on your list. Also, I'm curious, what's your default browser? I'm using FF Aurora, the tests run OK for me (not to say they don't have all these issues). |
@peterflynn, could you try the current master to see if all of your issues are gone? If not, we'll re-open this. Also, still need the info on the default browser you're using. |
Re-opening. I didn't mean to close this -- it must have auto-closed. |
1)
The Jasmine test-runner window always logs an exception when it is first loaded, before any tests are run:[console messages hidden](because bootstrap-twipsy-mod is not loaded in the Jasmine window)Fixed in #102852) Several LiveDevelopmentMultiBrowser tests fail for me with "timeout: timed out after 5000 msec waiting for livedevelopment.done.opened" (usually 2-3 tests fail per run).
3) The console is littered with error messages after running this test suite:
(twice)
(13 times - various listeners all with the same TypeError)
Even if these are caused by the timeouts above, it suggests the code does not fail gracefully in the event of a connection timeout.
4) One time this test suite seemed to get stuck with the Node process hanging onto file handles in the brackets/test/temp folder, which caused many other unit tests to fail since they were unable to clear that folder. Restating the Node process released the file handles. Depending on how easy it is to hit this failure case, we may want to do more to increase robustness...
The text was updated successfully, but these errors were encountered: