mirror of
https://github.com/gosticks/wordpress-develop.git
synced 2025-10-16 12:05:38 +00:00
237efb5304
Splits the tests in the `tests/phpunit/tests/compat.php` file up into individual test classes for each function being tested. Improvements to individual test cases: * Adds `@covers` tags. * Adds visibility modifiers to all methods. * Adds function availability test. * Where relevant, fixes the assertion parameter order. * Data provider: * Where relevant, reworks a test to use a data provider. * Where relevant, renames data provider methods to have a more obvious link to the test it applies to. * Makes the data provider more readable by adding keys within the data sets. * Moves the data provider below its associated tests. * Adds/removes data sets in data providers. * Makes the actual test code more readable by using descriptive variables and multi-line function calls. * Adds the `$message` parameter to all assertions when a test method contains more than one assertion. Specifically for the `_mb_substr()` tests: * Splits the `test_mb_substr_phpcore()` method into two test methods based on the PHP Core test files they are emulating. * Makes the actual test code within the `test_mb_substr_phpcore_basic()` method more readable by using descriptive variables and multi-line function calls. * Splits the data used for the second part of the `test_mb_substr_phpcore()` function, now `test_mb_substr_phpcore_input_type_handling()`, off into a separate data provider with named data sets. * Removes duplicate data sets from the `data_mb_substr_phpcore_input_type_handling()`. * Why? The PHP native tests test against upper/lowercase `false`, `true`, `null` and some other text string single quote/double quote variations. As things were, those differentiations had been undone when the coding standards were put in place, so in effect those weren't being tested anymore. And as this is userland code, there's no point in adding these differentiations back as they will be handled the same by PHP anyway (and that is safeguarded via the PHP native tests). * Removes the "undefined variable" and "unset variable" test cases as, while those are relevant to the C code in which PHP is written, they are not relevant for testing userland code and will behave the same as the test passing `null`. Follow-to [25002], [32364], [42228], [42343], [43034], [43036], [43220], [43571], [45607], [47122], [47198], [48937], [48996], [51415], [51563], [51594]. Props jrf, hellofromTonya. See #39265, #53363. git-svn-id: https://develop.svn.wordpress.org/trunk@51852 602fd350-edb4-49c9-b593-d223f7449a82 |
||
|---|---|---|
| .. | ||
| data | ||
| includes | ||
| tests | ||
| build.xml | ||
| multisite.xml | ||
| README.txt | ||
| wp-mail-real-test.php | ||
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.