Memory leak when running all unit tests

[gruehle]

Steps to repro

1. Open the unit test window.
2. Select "All" test suites
3. Select "All" tests
4. Wait a long time

Results
Brackets gets really sluggish and uses up tons of memory.

Expected
Should be able to run all tests without running out of memory.

[redmunds]

I think this thread in the requirejs forum describes the problem we're having and offers a solution: https://groups.google.com/forum/?fromgroups#!topic/requirejs/DtMnHdKlcVE

[njx]

Reviewed. Medium priority, nominating for sprint 27. @redmunds - would you like to look into this further (since you already looked into it a bit :))? If not, feel free to reassign.

[redmunds]

I think what we need to do is to unload (or "undefine") unit test modules after they are run.

The undef() method is part of requirejs (http://requirejs.org/docs/api.html#undef). A major caveat: "it will not remove the module from other modules that are already defined and got a handle on that module as a dependency when they executed", but that shouldn't affect unit test modules since they are independent.

Currently, unit test module require statements are hard-coded, so I think we need to dynamically load/unload each unit test module every time the tests are run. This means we'll have to refactor the code since Jasmine Spec Runner dialog is populated from module info.

[jasonsanjose]

I'm starting to think we're leaking memory due to closures. Randy's fix in #4313 addresses some of those issues around setup and teardown of a spec. There's a lot more work to do though.

[jasonsanjose]

I'm pretty certain now that we're leaking memory for every new brackets window we open.

Ignoring the integration tests (which are integrations tests because they open a new window), if I simply use the devtools timeline to measure memory while I open then close a series of windows view Debug > New Window, I see the Document and DOM Node counts climb up and up. GC helps some, but long after the windows are closed the Documents and DOM Nodes are still around.

See devtools graph:

[jasonsanjose]

I merged @redmunds pull request. But the bulk of this will need to be done in another sprint. Nominating sprint 28.

[njx]

Moving out to sprint 29 - seems like we have higher priority unit test failures to worry about.

[njx]

Removing from sprint since the main issue it was causing (#4547) is now much alleviated by the collapsing of multiple unit test windows into one (thanks to @TomMalbran as well as @jasonsanjose).