[wp-trac] [WordPress Trac] #55918: Call wpTearDownAfterClass() before deleting all data, instead of after

[WordPress Trac]

#55918: Call wpTearDownAfterClass() before deleting all data, instead of after
--------------------------------------+-----------------------------
 Reporter:  SergeyBiryukov            |       Owner:  SergeyBiryukov
     Type:  defect (bug)              |      Status:  closed
 Priority:  normal                    |   Milestone:  6.1
Component:  Build/Test Tools          |     Version:
 Severity:  normal                    |  Resolution:  fixed
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+-----------------------------
Changes (by SergeyBiryukov):

 * owner:  (none) => SergeyBiryukov
 * status:  new => closed
 * resolution:   => fixed


Comment:

 In [changeset:"54366" 54366]:
 {{{
 #!CommitTicketReference repository="" revision="54366"
 Build/Test Tools: Call `wpTearDownAfterClass()` before deleting all data,
 instead of after.

 As of [35186] and [51568], there are two sets of methods used for
 setup/teardown in the test suite before and after a test class is run:

 * `set_up_before_class()` / `tear_down_after_class()`
 * `wpSetUpBeforeClass()` / `wpTearDownAfterClass()`. (Note the `wp`
 prefix, these are WordPress' own methods and are not the same as the
 native PHPUnit `setUpBeforeClass()` / `tearDownAfterClass()` methods.)

 The main difference is that `wpSetUpBeforeClass()` receives the `$factory`
 argument for ease of use, and both `wpSetUpBeforeClass()` and
 `wpTearDownAfterClass()` don't need to call `self::commit_transaction()`.

 Many tests use the `wpTearDownAfterClass()` method to clean up posts,
 users, roles, etc. created via `wpSetUpBeforeClass()`. However, due to
 [source:tags/6.0/tests/phpunit/includes/abstract-
 testcase.php?marks=88-95#L82 how the method was previously called], this
 cleanup happened after all data is **already deleted** from the database.

 This could cause some confusion when refactoring tests. For example:
 {{{
 public static function wpTearDownAfterClass() {
         $GLOBALS['_wp_additional_image_sizes'] = self::$_sizes;
 }

 public static function tear_down_after_class() {
         wp_delete_attachment( self::$large_id, true );
         parent::tear_down_after_class();
 }
 }}}

 At a glance, it seems like these two methods can be combined:
 {{{
 public static function wpTearDownAfterClass() {
         wp_delete_attachment( self::$large_id, true );

         $GLOBALS['_wp_additional_image_sizes'] = self::$_sizes;
 }
 }}}
 However, that would not work as expected: by the time
 `wp_delete_attachment()` runs, the attachment ID is no longer in the
 database, so it returns early, leaving some files in the `uploads`
 directory.

 By calling `wpTearDownAfterClass()` in
 `WP_UnitTestCase_Base::tear_down_after_class()` before deleting all data,
 instead of after, we ensure that both of these methods have access to the
 same data and can be used interchangeably to perform cleanup as necessary.

 Additionally, this commit moves the calls to parent methods in
 `WP_UnitTestCase_Base`:

 * `parent::set_up_before_class()` to be the first thing called in
 `::set_up_before_class()`
 * `parent::tear_down_after_class()` to be the last thing called in
 `::tear_down_after_class()`

 This does not have any effect in practice, but brings consistency with how
 these methods are called in the test suite.

 Follow-up to [35186], [35225], [35242], [38398], [39626], [49001],
 [51568].

 Props ironprogrammer, SergeyBiryukov.
 Fixes #55918. See #55652.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/55918#comment:10>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform