While working on #352951: Make JS & CSS Preprocessing Pluggable, I got very much fed up with the extreme slowness of CascadingStylesheetsTest.php.
Difference
- Before: 281 seconds
- After: 8 seconds
- (That's 35.125 times faster, or only 2.85% 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
testRenderInlineFullPage() since it was rather pointless: it tests adding inline CSS, but that's already tested in two other tests, and in fact to do so it used the PHP filter of all things…
- Instead of relying on a certain page callback in
common_test module, which would indeed need WebTestBase, I just moved the relevant parts of common_test.module into the test itself (2 lines of code).
Comments
Comment #1
wim leersComment #3
wim leersTestbot failed to run 4 tests.
Comment #4
wim leers#1: cascadingstylesheetstest_35_times_faster-2026255-1.patch queued for re-testing.
Comment #6
wim leersThis is sad.
Comment #7
wim leers#1: cascadingstylesheetstest_35_times_faster-2026255-1.patch queued for re-testing.
Comment #8
dawehnerMaybe people would disagree, but I think if you manage to run your code in DrupalUnitTest it is a step forward to proper unit tests.
I try to understand why you need system. comment_test at least did not needed system module.
Comment #9
wim leersYes! Totally agreed.
It's necessary for this:
Without system module, the pre render callback (and other callbacks) are not registered, hence
drupal_render(array('#type' => 'styles', '#items' => array(…))will render to the empty string.(Also:
WebTestBasealways includes system module implicitly of course :))Comment #10
wim leersSimilar improvements for
JavaScriptTest: #2026349: Make JavaScriptTest 3200% faster.Comment #11
wim leers.
Comment #12
dawehnerCan't we just use htmlspecialchars() here instead of the str_replace()?
Comment #13
wim leersYes, we can, but there is no point in doing so, because we control the input, and the input uses only "&". If you find that necessary, I'll reroll.
Comment #14
dawehnerWell, I don't care to be honest.
Comment #15
sdboyer commentedyeah, this always should have been a unit test. this is great. +1 on the RTBC.
Comment #16
alexpottNice...
Committed 104b436 and pushed to 8.x. Thanks!
Comment #17
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 #18
wim leers#17: 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 #19
panchoAdded it to the New DrupalUnitTestBase change record instead.
Comment #20
dawehnerI am sorry but please let not add additional drupal unit tests to this change note. The class hierachy looks kind of cool.
