wordpress-develop/tests/phpunit
Tonya Mork 5b5d174a30 Code Modernization: Deprecate dynamic properties in WP_Text_Diff_Renderer_Table magic methods.
The unknown use of unknown dynamic property within the `WP_Text_Diff_Renderer_Table` property magic methods is now deprecated. A descriptive deprecation notice is provided to alert developers to declare the property on the child class extending `WP_Text_Diff_Renderer_Table`.

Changes in this commit:
* Adds a deprecation notice to the `__get()`, `__set()`, `__isset()`, `__unset()` magic methods, i.e. to alert and inform developers when attempting to get/set/isset/unset a dynamic property.
* Fixes `__get()` to explicitly returns `null` when attempting to get a dynamic property.
* Fixes `__set()` by removing the value return after setting a declared property, as (a) unnecessary and (b) `__set()` should return `void` [https://www.php.net/manual/en/language.oop5.overloading.php#object.set per the PHP handbook].
* Fixes `__isset()` to return `false` if not in the `$compat_fields`, as `isset()` and `__isset()` should always return `bool`:
   * [https://www.php.net/manual/en/language.oop5.overloading.php#object.isset `__isset()` in the PHP manual] 
   * [https://www.php.net/manual/en/function.isset.php `isset()` in the PHP manual] 
* Adds a test class with happy and unhappy paths for these changes.

For backward compatibility, no changes are made to the internal declared properties listed in `$compat_fields` and accessed through the magic methods. 

For example:
A child class uses a property named `$data` that is not declared as a property on the child class. When getting its value, e.g. `$user_query->data`, the `WP_Text_Diff_Renderer_Table::__get()` magic method is invoked, the following deprecation notice thrown, and `null` returned:

>The property `data` is not declared. Setting a dynamic property is deprecated since version 6.4.0! Instead, declare the property on the class.

=== Why not remove the magic methods, remove the `$compat_fields` property, and restore the properties `public`?

tl;dr Backward compatibility.

If a plugin adds a property to `$compat_fields` array, then sites using that plugin would experience (a) an `Undefined property` `Warning` (PHP 8) | `Notice` (PHP 7) and (b) a possible change in behavior.

=== Why not limit the deprecation for PHP versions >= 8.2?

tl;dr original design intent and inform

The magic methods and `$compat_fields` property were added for one purpose: to continue providing external access to internal properties declared on `WP_Text_Diff_Renderer_Table`. They were not intended to be used for dynamic properties.

Deprecating that unintended usage both alerts developers a change is needed in their child class and informs them what to change.

References: 
* Dynamic (non-explicitly declared) properties are deprecated as of PHP 8.2 and are expected to become a fatal error in PHP 9.0.
* A [https://www.youtube.com/live/vDZWepDQQVE?feature=share&t=10097 live open public working session] where these changes were discussed and agreed to.
* [https://wiki.php.net/rfc/deprecate_dynamic_properties PHP RFC: Deprecate dynamic properties.]

Follow-up to [28525], [31135].

Props antonvlasenko, rajinsharwar, jrf, markjaquith, hellofromTonya, SergeyBiryukov, desrosj, peterwilsoncc, audrasjb, costdev, oglekler, jeffpaul.
Fixes #58898.
See #56034.

git-svn-id: https://develop.svn.wordpress.org/trunk@56354 602fd350-edb4-49c9-b593-d223f7449a82
2023-08-03 18:11:36 +00:00
..
data Media: Adjust PDF upload handling to remove non-opaque alpha channels from previews. 2023-07-19 22:33:47 +00:00
includes Coding Standards: Use instanceof keyword instead of the is_a() function. 2023-08-03 12:08:30 +00:00
tests Code Modernization: Deprecate dynamic properties in WP_Text_Diff_Renderer_Table magic methods. 2023-08-03 18:11:36 +00:00
multisite.xml Build/Test Tools: Update PHPUnit configuration for PHPUnit 9.5.10/8.5.21+. 2021-09-26 03:11:18 +00:00
README.txt Docs: Remove double spaces in tests/phpunit/README.txt. 2022-04-29 13:31:48 +00:00
wp-mail-real-test.php Docs: Align spelling with American English. 2022-10-21 21:10:29 +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.