Recent updates to the unit testing infrastructure

Several changes have made their way into WordPress’ unit testunit test Code written to test a small piece of code or functionality within a larger application. Everything from themes to WordPress core have a series of unit tests. Also see regression. suite and its infrastructure recently. If you maintain a WordPress project (such as a pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party or website) that has its own test coverage, you may be interested in porting some of these changes to your test suite too. Here’s a round-up:

  • Tests which require Multisitemultisite Used to describe a WordPress installation with a network of multiple blogs, grouped by sites. This installation type has shared users tables, and creates separate database tables for each blog (wp_posts becomes wp_0_posts). See also network, blog, site to be enabled, or tests which should be excluded from running when Multisite is enabled, can now be placed into the new ms-required and ms-excluded groups to skip them automatically when the test requires Multisite to be in use, or when it requires Multisite to not be in use, respectively. In addition, the default configuration in phpunit.xml now excludes such test groups as appropriate without them being marked as skipped, which removes unwanted noise from PHPUnit’s reporting when run in verbose mode. See #40531.

Note: Please note that this usage example has been updated from a previous version of this post.

Example usage:

/**
 * @group ms-required
 */
function test_something_on_multisite() {
	// Run your Multisite-only assertions here
}

/**
 * @group ms-excluded
 */
function test_something_without_multisite() {
	// Run your single-site-only assertions here
}
  • XDebug is now disabled when running tests on Travis in order to speed up the builds. This resulted in a huge reduction in build times, up to 40% in some cases. See #39978.
  • The PHPUnit version used when running tests on Travis is now explicitly coupled to the PHP version in order to avoid incompatibilities such as the one caused when PHPUnit 6 was rolled out. See [40269] for the main change and #40100 and #40086 for more info.
  • A compatibility shim for PHPUnit 6+ has been added, which means the test suite will no longer cause fatal errors if you want to update to PHPUnit 6+ locally or, for example, you want to require it through a Composer dependency. See #39822.
  • Several tests which were previously skipped when the environment wasn’t suitable will now cause failures, for example tests which depend on constants such as DISALLOW_FILE_MODS not being set. This is to avoid hiding tests that never run and therefore never fail if the assertions contained within them would otherwise fail. If the core test suite begins failing on your local environment as a result, you should address the cause. See #40533.
  • The number of PHP versions which older branches are tested against on Travis has been significantly reduced in order to speed up build times for patch releases. This is most beneficial when security fixes are released and backported. As a general rule, branch builds except the latest branch are now only tested on the oldest supported version (5.2), the latest in the 5.x branch, and the latest in the 7.x branch. See #40407.

#dev-notes

Target Browser Coverage

Previously, we discussed the new editor and browser support within WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.. Following up on those conversations, we are officially ending support for Internet Explorer versions 8, 9, and 10, starting with WordPress 4.8.

Microsoft officially discontinued supporting these browsers in January 2016, and attempting to continue supporting them ourselves has gotten to the point where it’s holding back development. I realize that folks still running these browsers are probably stuck with them because of something out of their control, like being at a library or something. Depending on how you count it, those browsers combined are either around 3% or under 1% of total users, but either way they’ve fallen below the threshold where it’s helpful for WordPress to continue testing and developing against. (The numbers surprised me, as did how low IE market share overall has gone.)

Of course, wp-adminadmin (and super admin) should still work in these older browsers, but with fewer capabilities, and we will no longer be testing new features and enhancements in these browsers. For example, the next versions of TinyMCE – currently targeted at WordPress 4.8 – will not support older IE browsers.

As part of this change, we will work to update Browse Happy to show that these browsers are no longer supported and encourage users to upgrade or switch browsers.