The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.(This is the sister issue of #2026255: Make CascadingStylesheetsTest 3500% faster.)
While working on #352951: Make JS & CSS Preprocessing Pluggable, I got very much fed up with the extreme slowness of JavaScriptTest.php.
Difference
- Before: 610 seconds (10 min 10 sec)
- After: 19 seconds
- (That's 32.105 times faster, or only 3.11% of the original test running time.)
It used WebTestBase for historical reasons, while it could easily use DrupalUnitTestBase now.
Ideally, this would be a PHPUnit test, but that's not technically possible right now. This will at least make it a whole lot faster, while retaining the same test coverage.
Changes
I changed as little as possible:
DrupalWebTestBase->DrupalUnitTestBase- Removed the testing of the presence of
drupalSettings.currentPathin the actual rendered HTML; it's already being tested higher up intestHeaderSetting()anyway. - Instead of relying on a certain page callback in
common_testmodule, which would indeed needWebTestBase, I just moved the relevant parts ofcommon_test.moduleinto the test itself (2 lines of code).
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | javascripttest_32_times_faster-2026349-7.patch | 3.39 KB | wim leers |
| #4 | javascripttest_32_times_faster-2026349-4.patch | 2.8 KB | wim leers |
| #1 | javascripttest_32_times_faster-2026349-1.patch | 3.04 KB | wim leers |
Comments
Comment #1
wim leersComment #2
wim leers.
Comment #4
wim leersPostponed on #352951: Make JS & CSS Preprocessing Pluggable, this reroll is applied on top of that. So, marking as postponed until that patch gets committed.
Comment #5
wim leers#352951: Make JS & CSS Preprocessing Pluggable got committed, now this should pass tests and get to RTBC.
Comment #7
wim leersComment #9
wim leers#7: javascripttest_32_times_faster-2026349-7.patch queued for re-testing.
Comment #10
fubhy commentedWim, I love you.
Comment #11
nod_Looks good to me, what's left for RTBC?
Comment #12
nod_nothing apparently, the change for the query string is legit, don't need a page to make sure it works. Everything happens before the page is rendered.
Comment #13
panchoAwesome improvement, but why is it added to the Pluggable CSS & JS preprocessing change record? Let's instead create a separate change record "Vastly improved performance for many Simpletests" or so. It's no API change, but taken together it's very much noteworthy.
Comment #14
wim leers#13: we don't create change records for faster tests. I just referenced it in the pluggable CSS/JS change record because as part of working on that, I also did this. If it bothers you, feel free to remove it from that change record. You're right that it's strictly not functionally related.
Comment #15
amateescu commentedI also think that test improvements do not belong to a change record. After all, what's the audience for this.. 20-30 people? And they already know the difference between a web test and a unit test.
@Wim Leers, no offense, but I think you've been around marketing and sales people for too long :P
/me is looking forward to the next "stellar" thing :D
Comment #16
panchoAdded it to the New DrupalUnitTestBase change record instead
Comment #17
wim leers#15: haha :) You're right. I haven't been around a whole lot of marketing or sales people though :)
Comment #18
alexpottNice one... Committed cb7f315 and pushed to 8.x. Thanks!