wordpress-develop/tests/phpunit
Sergey Biryukov 17fb93149b Code Modernization: Fix "JsonSerializable_Object::jsonSerialize() should be compatible with JsonSerializable::jsonSerialize(): mixed" error on PHP 8.1.
This relates to the [https://wiki.php.net/rfc/internal_method_return_types Return types for internal methods RFC] in PHP 8.1 and in particular, the change made in [https://github.com/php/php-src/pull/7051 PHP PR #7051], which adds a `mixed` return type to the `JsonSerializable::jsonSerialize()` interface method.

WordPress only contains one (test) class which implements the `JsonSerializable` interface and this commit fixes the issue for that class.

As of PHP 8.1, the `jsonSerialize()` method in classes which implement the `JsonSerializable` interface are expected to have a return type declared. The return type should be `mixed` or a more specific type. This complies with the Liskov principle of covariance, which allows the return type of a child overloaded method to be more specific than that of the parent.

The problem with this is that:
1. The `mixed` return type was only introduced in PHP 8.0.
2. Return types in general were only introduced in PHP 7.0.

WordPress still has a minimum PHP version of 5.6, so adding the return type is not feasible for the time being.

The solution chosen for now is to add an attribute to silence the deprecation warning. While attributes are a PHP 8.0+ feature, due to the choice of the `#[]` syntax, in PHP < 8.0, attributes will just be ignored and treated as comments, so there is no drawback to using the attribute.

Props jrf.
See #53635.

git-svn-id: https://develop.svn.wordpress.org/trunk@51517 602fd350-edb4-49c9-b593-d223f7449a82
2021-07-30 14:46:30 +00:00
..
data Build: Split packages and blocks to their webpack configs 2021-07-28 10:05:01 +00:00
includes Code Modernization: Fix "JsonSerializable_Object::jsonSerialize() should be compatible with JsonSerializable::jsonSerialize(): mixed" error on PHP 8.1. 2021-07-30 14:46:30 +00:00
tests Build/Test Tools: Revert the test and coding standards changes in [51511]. 2021-07-29 20:02:53 +00:00
build.xml Coding Standards: Replace spaced indentation sections of phpunit.xml.dist, multisite.xml, and build.xml with tabs. 2019-01-28 17:20:06 +00:00
multisite.xml Build/Test Tools: Fix code coverage reporting to generate report from src. 2021-03-26 13:23:52 +00:00
README.txt Update tests/README.txt to reflect the new tests directory structure. props jdgrimes. fixes #25133. 2013-08-31 13:42:56 +00:00
wp-mail-real-test.php Code Modernization: Replace dirname( __FILE__ ) calls with __DIR__ magic constant. 2020-02-06 06:31:22 +00:00

The short version:

1. Create a clean MySQL database and user.  DO NOT USE AN EXISTING DATABASE or you will lose data, guaranteed.

2. Copy wp-tests-config-sample.php to wp-tests-config.php, edit it and include your database name/user/password.

3. $ svn up

4. Run the tests from the "trunk" directory:
   To execute a particular test:
      $ phpunit tests/phpunit/tests/test_case.php
   To execute all tests:
      $ phpunit

Notes:

Test cases live in the 'tests' subdirectory.  All files in that directory will be included by default.  Extend the WP_UnitTestCase class to ensure your test is run.

phpunit will initialize and install a (more or less) complete running copy of WordPress each time it is run.  This makes it possible to run functional interface and module tests against a fully working database and codebase, as opposed to pure unit tests with mock objects and stubs.  Pure unit tests may be used also, of course.

Changes to the test database will be rolled back as tests are finished, to ensure a clean start next time the tests are run.

phpunit is intended to run at the command line, not via a web server.