Widget leak detector during JS unit tests #30461
Conversation
|
@aab-odoo should I submit the fixes as individual PRs for you or @ged-odoo to approve, or should I just merge them myself? There also seems to be a recurring issue I'm not sure how to fix (just hide it maybe?): services are parented & get created by the mock thing, but they never get destroyed, and I don't know that there's a way to get a handle on them to destroy them explicitly (plus it would be inconvenient?) |
|
@xmo-odoo Services can be destroyed as they uses the ParentedMixin. Actually, they should be destroyed in addMockEnvironment (in the destroy override). |
|
@xmo-odoo We can review it. Just tell us when you're done. |
I was thinking the individual fixes being backported rather than this one, I'll probably be cherry-picking the fixes for the issues I found (e.g. missing super calls) to the relevant branch before this one is done. |
|
@xmo-odoo I agree, but we can still review each PR |
|
🆗 |
xmo-odoo
force-pushed
the
master-leakcheck-xmo
branch
5 times, most recently
from
7509306
to
702c32a
Compare
xmo-odoo
force-pushed
the
master-leakcheck-xmo
branch
from
702c32a
to
b5212e8
Compare
xmo-odoo
force-pushed
the
master-leakcheck-xmo
branch
from
6a2d9c4
to
5a6e6bf
Compare
xmo-odoo
force-pushed
the
master-leakcheck-xmo
branch
2 times, most recently
from
4466d04
to
a7732e9
Compare
xmo-odoo
force-pushed
the
master-leakcheck-xmo
branch
2 times, most recently
from
bb44058
to
ab35d16
Compare
Log an error if widgets created during a test are left undestroyed at its end. Note: ignore RamStorage because mail's testutils creates tons of them and provides no way to clean them up.
xmo-odoo
force-pushed
the
master-leakcheck-xmo
branch
from
ab35d16
to
ce3a5d7
Compare
|
Well after updating to the latest master, this checker looks useless as it finds no leak whatsoever (in community anyway). |
💪 |
Widgets have to be explicitly destroyed in unit tests. Non-trivial widgets which are not properly destroyed can lead to odd issues and failings in following tests (e.g. because they're intercepting events, have timers running, or are otherwise interfering with the widgets actually being tested).
This PR implements a "leak checker" of sorts: it records all the widgets created during the test, and fails if some of them are un-destroyed at the end. It also fixes extant instances of that issue.
Note that this will not catch all such leak checks: if a widget is created in an async callback and the test is not marked async (aka it's created after the tests has ended as far as qunit is concerned) it won't be detected.
It also doesn't handled the path issue: most tests only properly cleanup and terminate their tests in case no error happened (a deferred of some sort resolved correctly), this can cause cascading errors where one test failing would either lead to its timeout or interfere with further tests.