#53363 closed task (blessed) (fixed)
Test tool and unit test improvements for 5.9
Reported by: | desrosj | Owned by: | |
---|---|---|---|
Milestone: | 5.9 | Priority: | normal |
Severity: | normal | Version: | |
Component: | Build/Test Tools | Keywords: | has-patch has-unit-tests |
Focuses: | Cc: |
Attachments (13)
Change History (156)
This ticket was mentioned in Slack in #core by sergey. View the logs.
3 years ago
@
3 years ago
Annotate when tests do deliberately do not perform assertions, so the test won't be marked as risky
@
3 years ago
Use more appropriate assertion [1] - this assertion is available PHPUnit cross-version, so can already be used
@
3 years ago
Use more appropriate assertion [2] - this assertion is available PHPUnit cross-version, so can already be used
#23
follow-up:
↓ 28
@
3 years ago
Note: both methods used in the above two patches were introduced in PHPUnit 5.6.0. As the test runs on PHPUnit 5.x use PHPUnit 5.7.27, this shouldn't be an issue, though the test bootstrap.php
file does give the impression that PHPUnit 5.4 is still supported (though I don't understand why we'd want to support anything but the last version of the PHPUnit 5.x series).
@
3 years ago
Build/Tests: custom assertions should always have a $message parameter All assertions in PHPUnit have a $message
parameter. Setting this parameter allows to distinguish which assertion is failing when a test runs multiple assertion, making debugging of the tests easier. The WP custom assertions which are included in the WP_UnitTestCase_Base
class should also allow for this $message
parameter. This patch adds this - optional - parameter for those assertions which were missing it.
#24
@
3 years ago
Putting a hold on patch 53363-01.patch
/cc @johnbillion
There is something weird going on with this.
- If the tests are run with
WP_RUN_CORE_TESTS
set to0
, those tests are marked as "risky" due to not performing any assertions. The patch would fix that. - However, if the tests are run with
WP_RUN_CORE_TESTS
set to1
+ this patch applied, those same tests are marked as "risky" saying that 4 assertions were run - even though the tests are empty.
This leads me to believe that somewhere assertions are being used within a fixture method (setUp()
et al). This is bad practice and should not be allowed.
I've not dug in any deeper yet, but I do believe that this underlying issue needs to be solved first before this patch can be accepted.
This ticket was mentioned in Slack in #core by sergey. View the logs.
3 years ago
#26
@
3 years ago
Yes there are definitely non-test methods in the test suite that perform assertions. I'll try to dig them out.
#28
in reply to:
↑ 23
;
follow-up:
↓ 33
@
3 years ago
Replying to jrf:
Note: both methods used in the above two patches were introduced in PHPUnit 5.6.0. As the test runs on PHPUnit 5.x use PHPUnit 5.7.27, this shouldn't be an issue, though the test
bootstrap.php
file does give the impression that PHPUnit 5.4 is still supported (though I don't understand why we'd want to support anything but the last version of the PHPUnit 5.x series).
Right, WordPress test suite still supports PHPUnit 5.4.x as the minimum version as of [47880].
That said, I don't see any issue with bumping that requirement to PHPUnit 5.7.x.
#29
@
3 years ago
Here's a few I found from a quick listener I knocked up. There's likely more.
Tests_WP_Customize_Widgets::setUp()
: https://github.com/WordPress/wordpress-develop/blob/92c454cec6c214c29ca54859c79d47a8f7d9fa68/tests/phpunit/tests/customize/widgets.php#L67-L73Tests_AdminBar::get_standard_admin_bar()
: https://github.com/WordPress/wordpress-develop/blob/92c454cec6c214c29ca54859c79d47a8f7d9fa68/tests/phpunit/tests/adminbar.php#L247-L248WP_Test_REST_Controller_Testcase::filter_rest_url_for_leading_slash()
: https://github.com/WordPress/wordpress-develop/blob/92c454cec6c214c29ca54859c79d47a8f7d9fa68/tests/phpunit/includes/testcase-rest-controller.php#L48Tests_User_Session::setUp()
: https://github.com/WordPress/wordpress-develop/blob/92c454cec6c214c29ca54859c79d47a8f7d9fa68/tests/phpunit/tests/user/session.php#L15-L16WP_Test_XML_TestCase::loadXML()
: https://github.com/WordPress/wordpress-develop/blob/92c454cec6c214c29ca54859c79d47a8f7d9fa68/tests/phpunit/includes/testcase-xml.php#L22-L25WP_Import_UnitTestCase::_import_wp()
: https://github.com/WordPress/wordpress-develop/blob/92c454cec6c214c29ca54859c79d47a8f7d9fa68/tests/phpunit/tests/import/base.php#L27-L28
#30
@
3 years ago
WP_Test_REST_Controller_Testcase::filter_rest_url_for_leading_slash()
would seem the most likely culprit.
The function is added as a callback to a filter in the (parent) WP_Test_REST_Controller_Testcase::setUp()
and the rest_api_init
action is also called during setUp()
- I still have to trace whether that causes the filter_rest_url_for_leading_slash()
method to run, but seems likely, though that one filter callback being called four times during setUp()
does feel like there may be an underlying bug in the REST API Controller logic anyway.
While looking at this, I also noticed another issue with the setUp()
and tearDown()
: setUp()
adds the filter_rest_url_for_leading_slash()
method as a callback, but tearDown()
tries to remove test_rest_url_for_leading_slash()
as a callback.
Not a real problem as the WP_UnitTestCase_Base::tearDown()
calls WP_UnitTestCase_Base::_restore_hooks()
which reset the hooks queue to its original state, but just thought I'd mention it as it does seem off.
#31
@
3 years ago
Confirmed: commenting out the assertion in the filter_rest_url_for_leading_slash()
method removes the "This test is annotated with "@doesNotPerformAssertions" but performed 4 assertions" risky warning.
Still have to dig in deeper to figure out where the callback is triggered and what should be done with it.
#32
@
3 years ago
One more:
Tests_DB_Charset::data_strip_invalid_text()
(assertions inside a data provider, nice): https://github.com/WordPress/wordpress-develop/blob/92c454cec6c214c29ca54859c79d47a8f7d9fa68/tests/phpunit/tests/db/charset.php#L418-L419
#33
in reply to:
↑ 28
;
follow-up:
↓ 50
@
3 years ago
Replying to SergeyBiryukov:
Replying to jrf:
Right, WordPress test suite still supports PHPUnit 5.4.x as the minimum version as of [47880].
That said, I don't see any issue with bumping that requirement to PHPUnit 5.7.x.
@SergeyBiryukov FYI: The requirement will be raised to 5.7.21
in the polyfills patch anyway, so we could just wait a little for that patch to land before those two assertion change patches get committed ?
(assertions inside a data provider, nice)
@johnbillion Ouch... nice find though. I think we should aim to fix all of these in the foreseeable future.
#39
@
3 years ago
Found something else which needs looking into, where the tests clearly aren't self-contained:
If I add the import
group to the <groups>
<excludes>
, then the following two unrelated tests start erroring out:
#) Tests_Embed_Template::test_oembed_output_post_with_thumbnail DOMDocument::loadHTML(): AttValue: " expected in Entity, line: 10 path/to/wp/tests/phpunit/tests/oembed/template.php:66 #) Tests_Embed_Template::test_oembed_output_attachment DOMDocument::loadHTML(): AttValue: " expected in Entity, line: 10 path/to/wp/tests/phpunit/tests/oembed/template.php:110
This ticket was mentioned in PR #1519 on WordPress/wordpress-develop by jrfnl.
3 years ago
#41
- Keywords has-patch has-unit-tests added
### QA: move incorrectly placed test file
The Block_Supported_Styles_Test
class is not a TestCase
to be extended, but an actual concrete test class.
Note: the tests as-is are failing. This should be fixed before this can be merged.
Includes minor CS fixes and adding the $message
parameter to assertions to aid in debugging.
### Block_Supported_Styles_Test: update the style related test to current expected format
### Block_Supported_Styles_Test: remove two outdated tests
The functionality which these tests were testing is no longer available in this manner, so these tests are redundant.
Trac ticket: https://core.trac.wordpress.org/ticket/53363
#42
@
3 years ago
I've just opened PR 1519 which is a collaborative effort between @aristath and me with some consulting from @youknowriad to fix a misplaced test.
The test was in the phpunit/includes
directory, meaning it was never actually run.
When fixing the location though, turned out the tests were failing.
All fixed now and ready for review/commit.
#43
in reply to:
↑ 40
@
3 years ago
Replying to johnbillion:
@jrf Thanks, can you open a separate ticket for that please?
3 years ago
#45
Closing as committed via https://core.trac.wordpress.org/changeset/51490
This ticket was mentioned in Slack in #core by sergey. View the logs.
3 years ago
#50
in reply to:
↑ 33
@
3 years ago
Replying to jrf:
Replying to SergeyBiryukov:
Replying to jrf:
Right, WordPress test suite still supports PHPUnit 5.4.x as the minimum version as of [47880].
That said, I don't see any issue with bumping that requirement to PHPUnit 5.7.x.
@SergeyBiryukov FYI: The requirement will be raised to
5.7.21
in the polyfills patch anyway, so we could just wait a little for that patch to land before those two assertion change patches get committed ?
Both the 53363-02-use-assertfileisreadable.patch
and the 53363-03-use-assertdirectoryexists.patch
changes are now unblocked after the commits made for #47381, which raised the minimum PHPUnit version to 5.7.x as the assertion functions being introduced in those patches are available since PHPUnit 5.6.0.
@
3 years ago
Build/Tests: fix message display in test bootstrap Any messages to the user which are echo-ed out in the test bootstrap will generally display on a command-line interface. The *nix specific "\n"
line ending will be ignored on Windows, making the messages less readable. For new lines in CLI messages, PHP_EOL
should be used instead. This was already done in a few places in the script, but not consistently so. Fixed now.
@
3 years ago
PHPUnit config files: add schema reference The current config files validate against the PHPUnit XSD schema for config files for PHPUnit 5.7 - 9.2. The schema was changes in PHPUnit 9.3 and the filter
and logging
configuration deprecated in favour of coverage
and a different format for logging
. By setting the schema, deprecation notices about the use of an outdated schema when running on PHPUnit 9.3+ are prevented.
@
3 years ago
Build/Tests: testcases should be abstract TestCases which are intended to be extended and not run directly, should be abstract
.
#54
@
3 years ago
Just noting that I was confused by 53363-07-add-schema-to-config.patch at first, as I still see a deprecated schema warning in PHPUnit 9.3+ with this patch, both locally and on GitHub:
Warning: Your XML configuration validates against a deprecated schema. Suggestion: Migrate your XML configuration using "--migrate-configuration"!
It looks like either this message or a more detailed one:
Warning - The configuration file did not pass validation! The following problems have been detected: ... Test results may not be as expected.
is displayed in TestRunner::run()
, depending on whether a schema is detected.
Per discussion with @jrf, the first warning will remain and is fine. Only when PHPUnit 10 comes into play we should look into adding a run step to CI to call the --migrate-configuration
command. The patch is supposed to silence the second, more detailed warning, displayed in PHPUnit 9.3+ when an old configuration file is used.
Looking at the SchemaDetector
class, it attempts to validate the configuration file against the available schema files, as per the SchemaFinder class.
In my testing with PHPUnit 9.5.8, the configuration file successfully validates against the PHPUnit 9.2 schema with or without it being explicitly declared, so the detailed message is never displayed and the patch does not seem to make a difference. Still, I guess it's better to declare the schema explicitly for clarity.
@
3 years ago
Tests bootstrap: improve an outdated error condition The PHPUnit tests are/should generally be run on the src
directory, so changes just made can be tested. While testing via the build
directory is also still supported, this is not the default. This was last changed in [50441], but that commit did not remove/update the error message thrown by the test bootstrap file. This last change also did not take into account that that change meant that people had to update their own wp
tests-config.php file to match the change made in Core and would otherwise still get the outdated error message. This commit changes the messaging in the test bootstrap file to be more in line with the current reality, while still accounting for the fact that tests can be run from both
src as well as
build`.
#71
@
3 years ago
@jrf and I discussed 53363-09-test-bootstrap-improve-error-msg.patch per notes she added to the patch attachment. I tested before and after with each scenario. Works as expected.
Test Report
Env:
- WordPress: trunk
- OS: macOS Big Sur
- localhost: npm / Docker
Setup:
npm install npm run build:dev npm run env:start npm run env:install composer install
Scenario 1: ABSPATH
is build
but build folder does not exist
Steps:
- Change the
ABSPATH
tobuild
in thewp-tests-config.php
file:define( 'ABSPATH', dirname( __FILE__ ) . '/build/' );
- Run the tests (here running one group of tests but could be any group or all tests)
npm run test:php -- --group formatting
Results:
Before patch:
Error: The /build/ directory is missing! Please run `npm run build` prior to running PHPUnit.
After applying patch:
Error: The PHPUnit tests should be run on the /src/ directory, not the /build/ directory. Please update the ABSPATH constant in your `wp-tests-config.php` file to `dirname( __FILE__ ) . '/src/'` or run `npm run build` prior to running PHPUnit.
Works as expected ✅
Scenario 2: ABSPATH
is not src
or build
and the folder does not exist
Steps:
- Change the
ABSPATH
todoesnotexist
in thewp-tests-config.php
file:define( 'ABSPATH', dirname( __FILE__ ) . '/doesnotexist/' );
- Run the tests (here running one group of tests but could be any group or all tests)
npm run test:php -- --group formatting
Results:
Before patch:
Error: The /build/ directory is missing! Please run `npm run build` prior to running PHPUnit.
After applying patch:
Error: The ABSPATH constant in the `wp-tests-config.php` file is set to a non-existent path "/var/www/doesnotexist/". Please verify.
Works as expected ✅
Scenario 3: ABSPATH
is build
and build folder exists
Steps:
- In command-line, run:
npm run build
- Change the
ABSPATH
tobuild
in thewp-tests-config.php
file:define( 'ABSPATH', dirname( __FILE__ ) . '/build/' );
- Run the tests (here running one group of tests but could be any group or all tests)
npm run test:php -- --group formatting
Results:
No errors. Tests run. Works as expected ✅
#72
@
3 years ago
Whoopsie, I forgot to add the ticket number to changeset [51669]. Commenting here to (manually) link the changeset to this ticket.
In 51669:
Tests: Improve bootstrap error message for when ABSPATH folder does not exist.
The PHPUnit tests are/should generally be run on the src directory, so changes just made can be tested. While testing via the build directory is also still supported, this is not the default.
This was last changed in [50441], but that commit did not remove/update the error message thrown by the test bootstrap file.
This last change also did not take into account that that change meant that people had to update their own wptests-config.php` file to match the change made in Core and would otherwise still get the outdated error message.
This commit changes the messaging in the test bootstrap file to be more in line with the current reality, while still accounting for the fact that tests can be run from both src as well as build.
Follow-up to [49569], [50441], [51581].
Props jrf, hellofromTonya.
@
3 years ago
WP_UnitTestCase_Base: more improvements to custom assertions The assertEqualFields()
method expects an object and a fields array as inputs and subsequently approaches the received parameters as such, but did not verify whether the received parameters are of the expected types. Along the same lines, the assertSameSets()
, assertEqualSets()
, assertSameSetsWithIndex()
and the assertEqualSetsWithIndex()
methods all expect arrays for both the actual as well as the expected values and uses the array function [k]sort()
on both, but never verified that the received inputs were actually arrays, which could lead to PHP errors on the sorting function calls.
@
3 years ago
WP_UnitTestCase_Base::assertDiscardWhitespace(): stabilize the custom assertion The assertDiscardWhitespace()
method uses assertEquals()
under the hood, meaning that in reality any type of actual/expected value should be accepted by the function. Fixed the documentation to reflect that. At the same time, only strings can contain whitespace differences, so the whitespace replacement should only be done when string values are passed. This will prevent potential passing null to non-nullable
errors on PHP 8.1, if either of the inputs would turn out to be null
.
#80
@
3 years ago
Whoopsie attached changeset [51817] to the wrong ticket. It belongs on this ticket.
In 51817:
Build/Test Tools: Reworks Tests_Option_Option::test_bad_option_names()
into a data provider.
The existing tests were running multiple functions through a foreach()
. If any test failed, it would bail out and not test against the other scenarios.
This commit:
- Moves the scenarios to a data provider with named data sets, i.e. to ensure all scenarios are run and tested regardless if any fail.
- Splits each function under test into individual test methods.
- Adds a float scenario.
- Adds method visibility modifiers.
Follow-up to [25002].
Props jrf, hellofromTonya, pbearne.
See #53635.
This ticket was mentioned in PR #1709 on WordPress/wordpress-develop by ntwb.
3 years ago
#86
Trac ticket: https://core.trac.wordpress.org/ticket/53363
Whilst running PHPUnit locally I noticed this message from PHPUnit 9.3:
Warning: Your XML configuration validates against a deprecated schema.
Suggestion: Migrate your XML configuration using "--migrate-configuration"!
I broke down the commits in this PR to aid code-review, one commit for each PHPUnit XML file, and additional commits for white-space cleanup.
This ticket was mentioned in Slack in #core-test by netweb. View the logs.
3 years ago
3 years ago
#89
Closing per comment https://core.trac.wordpress.org/ticket/54183#comment:13
Note: I would recommend against the config file update for the PHPUnit 9.3+ schema for now (PR 1709).
The old config will work fine for the time being and works cross-version, while the PHPUnit 9.3+ config would only work for PHPUnit 9.3+.
By the time PHPUnit 10 comes out (and the old config is no longer supported in PHPUnit 10), we can start to use the "on the fly" migrate option in CI if needs be:
phpunit --migrate-configuration
This ticket was mentioned in PR #1771 on WordPress/wordpress-develop by desrosj.
3 years ago
#91
This converts the slack-notifications.yml
workflow into a reusable one that can be called within other workflows.
This will eliminate the need for a separate Slack Notifications workflow to run every time a workflow run completes after a push
event.
Trac ticket: https://core.trac.wordpress.org/ticket/53363
This ticket was mentioned in PR #1771 on WordPress/wordpress-develop by desrosj.
3 years ago
#92
This converts the slack-notifications.yml
workflow into a reusable one that can be called within other workflows.
This will eliminate the need for a separate Slack Notifications workflow to run every time a workflow run completes after a push
event.
Trac ticket: https://core.trac.wordpress.org/ticket/53363
#98
in reply to:
↑ 93
@
3 years ago
Replying to desrosj:
In 51921:
It looks like this works for core commits, but breaks on PRs, see this job for example, or any subsequent PR to the wordpress-develop
repo:
Run actions/github-script@441359b1a30438de65712c2fbca0abe4816fa667 with: script: const previous_runs = await github.rest.actions.listWorkflowRuns({ owner: 'WordPress', repo: 'wordpress-develop', workflow_id: 3023044, branch: '1736/merge', per_page: 1, page: 2, }); return previous_runs.data.workflow_runs[0].conclusion; github-token: *** debug: false user-agent: actions/github-script result-encoding: json (node:1870) [DEP0005] DeprecationWarning: Buffer() is deprecated due to security and usability issues. Please use the Buffer.alloc(), Buffer.allocUnsafe(), or Buffer.from() methods instead. TypeError: Cannot read property 'conclusion' of undefined at eval (eval at callAsyncFunction (/home/runner/work/_actions/actions/github-script/441359b1a30438de65712c2fbca0abe4816fa667/dist/index.js:4942:56), <anonymous>:11:44) at processTicksAndRejections (internal/process/task_queues.js:93:5) at async main (/home/runner/work/_actions/actions/github-script/441359b1a30438de65712c2fbca0abe4816fa667/dist/index.js:4997:20) Error: Unhandled error: TypeError: Cannot read property 'conclusion' of undefined
This ticket was mentioned in Slack in #core by sergey. View the logs.
3 years ago
This ticket was mentioned in Slack in #core by sergey. View the logs.
3 years ago
This ticket was mentioned in PR #1901 on WordPress/wordpress-develop by desrosj.
3 years ago
#110
Trac ticket: https://core.trac.wordpress.org/ticket/53363
This ticket was mentioned in PR #1923 on WordPress/wordpress-develop by johnbillion.
3 years ago
#112
Trac ticket: https://core.trac.wordpress.org/ticket/53363
This ticket was mentioned in PR #1924 on WordPress/wordpress-develop by johnbillion.
3 years ago
#113
By default, GHA jobs can run for 6 hours before timing out. The timeout-minutes
directive allows this to be reduced in order to protect the repository against runaway or stuck processes.
I've given each job a very generous allowance. The idea is to reduce the timeout from its default 6 hours, but not to risk the job hitting the limit.
- 20 minutes for all regular test jobs
- 120 minutes for the long-running coverage job
- 5 minutes for quick jobs like Slack notifications
Refs:
- https://docs.github.com/en/actions/learn-github-actions/workflow-syntax-for-github-actions#jobsjob_idtimeout-minutes
- https://twitter.com/jaredpalmer/status/1392865882934849543
Trac ticket: https://core.trac.wordpress.org/ticket/53363
johnbillion commented on PR #1924:
3 years ago
#116
Committed in https://core.trac.wordpress.org/changeset/52233
3 years ago
#119
Committed to SVN in https://core.trac.wordpress.org/changeset/51921.
This ticket was mentioned in Slack in #core by sergey. View the logs.
3 years ago
This ticket was mentioned in PR #1943 on WordPress/wordpress-develop by johnbillion.
3 years ago
#121
This corrects the order of the expected and actual parameters when used in assertions so if/when they fail the failure message is correct.
Trac ticket: https://core.trac.wordpress.org/ticket/53363
johnbillion commented on PR #1943:
3 years ago
#123
#125
follow-up:
↓ 126
@
3 years ago
@SergeyBiryukov Wondering a little about [52253] as the expectOutputRegex()
is native PHPUnit, so PHPUnit was already handling the output caching.... The expectation was just set too late in the test code.
#126
in reply to:
↑ 125
;
follow-up:
↓ 127
@
3 years ago
Replying to jrf:
The expectation was just set too late in the test code.
Yeah, I was considering moving the expectOutputRegex()
call instead, but in my understanding that would mean restore_previous_locale()
would have to run after it and could potentially never be called in case of failure, affecting other tests.
#127
in reply to:
↑ 126
;
follow-up:
↓ 128
@
3 years ago
Replying to SergeyBiryukov:
Replying to jrf:
Yeah, I was considering moving theexpectOutputRegex()
call instead, but in my understanding that would meanrestore_previous_locale()
would have to run after it and could potentially never be called in case of failure, affecting other tests.
Ah, I understand. However, there is a difference between assertions - which will fail the test on the first failed assertion - and these type of output expectations - which will evaluate the output after the rest of the test code has run (providing no unexpected errors were encountered) -.
So moving the expectation up to before the function call generating the output, would be the way to go in this case.
This ticket was mentioned in PR #1995 on WordPress/wordpress-develop by johnbillion.
3 years ago
#133
Several tests perform assertions conditionally or iterate dynamic arrays without ensuring they're populated. If the test is faulty and the condition never evaluates to true or the array being iterated is empty then we'll never know about it.
This adds additional assertions that cover these situations.
Trac ticket: https://core.trac.wordpress.org/ticket/53363
#141
@
3 years ago
- Resolution set to fixed
- Status changed from new to closed
With 5.9 RC1 tomorrow, closing this ticket. Work will continue in #54725 during the 6.0 cycle.
johnbillion commented on PR #1995:
3 years ago
#142
Thanks for the comments @jrfnl , I've pushed some changes. I've left the whitespace unadjusted for now to keep the diff clean, the whitespace can be corrected at the point of commit.
Next up, we've actually got some failures as a result of these additional assertions that need investigating.
In 51333: