* Automatically delete objects that we were created during `wpSetUpBeforeClass` - posts, comments, terms (except 1), and user (except 1)
* The amount of leftover data between tests was breathtaking - use the new function: `_delete_all_data()`
* Commit database transactions for all `TestCase`s, not just those that implement `wpSetUpBeforeClass` and `wpTearDownAfterClass`
* The tests run 10-20 seconds faster now
See #37699.
git-svn-id: https://develop.svn.wordpress.org/trunk@38398 602fd350-edb4-49c9-b593-d223f7449a82
* Move the array processing to a new function, `_wp_post_revision_data()`.
* Make both functions accept a post array or a `WP_Post` object.
* Always apply the `_wp_post_revision_fields` filter and pass the post data to it.
Fixes#13382.
git-svn-id: https://develop.svn.wordpress.org/trunk@36659 602fd350-edb4-49c9-b593-d223f7449a82
Using more than one instance of `WP_UnitTest_Factory` causes all kinds of craziness, due to out-of-sync internal generator sequences. Since we want to use `setUpBeforeClass`, we were creating ad hoc instances. To avoid that, we were injecting one `static` instance via Dependency Injection in `wpSetUpBeforeClass`. All tests should really use the `static` instance, so we will remove the instance prop `$factory`.
Replace `$this->factory` with `self::$factory` over 2000 times.
Rewrite all of the tests that were hard-coding dynamic values.
#YOLOFriday
git-svn-id: https://develop.svn.wordpress.org/trunk@35225 602fd350-edb4-49c9-b593-d223f7449a82
`WP_UnitTestCase::tearDown()` restores the test environment to the default
conditions, including rolling back the MySQL transaction that the test takes
place in, resetting globals, and unhooking test-specific filters. As such, all
teardown routines for specific tests should happen before the parent class's
`tearDown()` method is called. Failure to do so can cause database locks on
certain configurations, among other problems.
See #31537.
git-svn-id: https://develop.svn.wordpress.org/trunk@31622 602fd350-edb4-49c9-b593-d223f7449a82
`test_revision_order()` was written ([28541], #26042) to ensure that revision
order was properly preserved in two different cases: (1) where the post_date
varied (in which case the revisions would be sorted by post_date DESC) and
(2) where the post_date was the same (in which case sorting would fall back on
ID DESC). In an attempt to ensure that both of these scenarios arose in the
context of a single test, 100 posts were created. We can make the process far
more efficient by manually creating the revisions with the post_dates
explicitly declared, and splitting the two different cases into two separate
test methods.
This test was previously the single worst offender in the entire suite, taking
upwards of 15 seconds to run. All that most maddens and torments; all that stirs
up the lees of things; all truth with malice in it; all that cracks the sinews
and cakes the brain; all the subtle demonisms of life and thought; all evil, to
crazy Boone, were visibly personified, and made practically assailable in
`test_revision_order()`.
See #30017.
git-svn-id: https://develop.svn.wordpress.org/trunk@30511 602fd350-edb4-49c9-b593-d223f7449a82
* Since `orderby` in `WP_Query` can accept space-delimited sets, yet only one `order` value: when multiple values are passed (and `DESC` is the order), the default sort order `ASC` is being applied to all values before the last in the set.
* There is a unit test that sporadically fails since 3.6 in `tests/post/revision` due to multiple posts having the same `post_date` from being added so rapidly
* When ordering revisions in `wp_get_post_revisions()`, order by `post_date ID`
* Change the `order` value in `wp_get_post_revisions()` to `ASC`. This will produce SQL like: `ORDER BY $wpdb->posts.post_date ASC, $wpdb->posts.ID ASC`. Previously, this would have produced SQL like: `ORDER BY $wpdb->posts.post_date DESC`, and with the addition of ` ID`: `ORDER BY $wpdb->posts.post_date ASC, $wpdb->posts.ID DESC`. Clearly, wrong. The original SQL produced: `ORDER BY $wpdb->posts.post_date DESC`. As such, return the reversions in reverse order using `array_reverse()`. Not doing so would break "Preview Changes."
* Add unit tests to assert that all of this works.
* All existing unit tests pass with the change to ordering multiple `orderby`s in `WP_Query`.
* In the future, we should support independent `order` for each `orderby`, see #17065.
Props SergeyBiryukov, wonderboymusic.
Fixes#26042.
git-svn-id: https://develop.svn.wordpress.org/trunk@28541 602fd350-edb4-49c9-b593-d223f7449a82
wp-tests-config.php can/should reside in the root of a develop checkout. `phpunit` should be run from the root.
see #25088.
git-svn-id: https://develop.svn.wordpress.org/trunk@25165 602fd350-edb4-49c9-b593-d223f7449a82
Scott Taylor