3fbb8ed287
* Introduce a new `wp.customize.previewer.trash()` JS API to trash the current changeset, along with logic to `WP_Customize_Manager` to handle deleting changeset drafts. * Add `trashing` to `wp.customize.state` which is then used to update the UI. * UI for trashing is pending design feedback. One possibility is to add a new trash button to Publish Settings section that invokes `wp.customize.previewer.trash()`. * Improve logic for managing the visibility and disabled states for publish buttons. * Prevent attempting `requestChangesetUpdate` while processing and bump processing while doing `save`. * Update `changeset_date` state only if sent in save response. * Merge `ThemesSection#loadThemePreview()` into `ThemesPanel#loadThemePreview()`. * Remove unused `autosaved` state. * Start autosaving and prompting at beforeunload after a change first happens. This is key for theme previews since even if a user did not make any changes, there were still dirty settings which would get stored in an auto-draft unexpectedly. * Allow `Notification` to accept additional `classes` to be added to `container`. * Introduce `OverlayNotification` and use for theme installing, previewing, and trashing. Such overlay notifications take over the entire window. Props westonruter, celloexpressions. See #37661, #39896, #21666, #35210. git-svn-id: https://develop.svn.wordpress.org/trunk@41667 602fd350-edb4-49c9-b593-d223f7449a82 |
||
|---|---|---|
| .. | ||
| data | ||
| includes | ||
| tests | ||
| README.txt | ||
| build.xml | ||
| multisite.xml | ||
| wp-mail-real-test.php | ||
README.txt
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.