mirror of
https://github.com/gosticks/wordpress-develop.git
synced 2025-10-16 12:05:38 +00:00
323ac54d4b
This was added to avoid creating leftover image sub-sizes in the version-controlled `DIR_TESTDATA` directory. However, this does not appear to be necessary: * `WP_Customizer_Manager::import_theme_starter_content()` already [source:tags/6.0.2/src/wp-includes/class-wp-customize-manager.php?marks=1370-1374#L1367 makes a copy of the image] before sideloading, so the test was essentially working with a copy of a copy. * The images were only used in one test out of 70 and do not need to be copied for every single test. Upon further investigation, there is also no evidence that creating these copies actually resolved the reported issue: * `WP_UnitTest_Factory_For_Attachment::create_object()` inserts an attachment, but does not create image sub-sizes. * `media_handle_sideload()` does create image sub-sizes, but the file is already in the media library by that time, and sub-sizes are created in the `uploads` directory, not in the version-controlled `DIR_TESTDATA` directory. This commit removes ~140 redundant file copying operations when running the test suite. Follow-up to [39276], [39346], [39411], [40142]. See #55652. git-svn-id: https://develop.svn.wordpress.org/trunk@54424 602fd350-edb4-49c9-b593-d223f7449a82 |
||
|---|---|---|
| .. | ||
| data | ||
| includes | ||
| tests | ||
| 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.