[wp-trac] [WordPress Trac] #56706: Tests: `parent::set_up()` calls `wp_list_pluck()`, causing inaccurate coverage.

[WordPress Trac]

#56706: Tests: `parent::set_up()` calls `wp_list_pluck()`, causing inaccurate
coverage.
----------------------------------------------+-----------------------
 Reporter:  costdev                           |       Owner:  costdev
     Type:  defect (bug)                      |      Status:  assigned
 Priority:  normal                            |   Milestone:  6.1
Component:  Build/Test Tools                  |     Version:
 Severity:  normal                            |  Resolution:
 Keywords:  has-screenshots has-patch commit  |     Focuses:
----------------------------------------------+-----------------------

Comment (by jrf):

 Replying to [comment:5 SergeyBiryukov]:
 > > So swopping out one WP native function for another is not a solution,
 it just "moves" the problem to another part of the test suite.
 >
 > I might be missing something, but [attachment:"56706.2.diff"] does not
 replace `wp_filter_object_list()` with any other native WP function, it
 just uses the globals directly. It was an attempt to implement this
 suggestion from the ticket description:
 > > The real solution involves ensuring that the code under test is not
 called in `WP_UnitTestCase_Base::set_up()`.

 Appreciated, My comment wasn't directly aimed at your patch, but the
 problem with using globals is, of course, that you need to be sure those
 globals have not been adjusted in the tests and if they have, that those
 globals will need to be reset after each test again too.

 To be honest, I think we need to leave the more structural solution to
 #53011, #53746 and the more structural test suite refactor and "all test
 review" in #53010.

 My line of thinking for a more structural solution would be to have a very
 "plain" base abstract TestCase which only contains the WP native
 assertions and expectation handling.

 And then have a number of abstract TestCases which can be used for
 specific test situations, something like `CleanDatabaseTestCase`,
 `EmptyCacheTestCase` etc (just some ideas, the real TestCases needed would
 need to be determined based on a detailed analysis of the tests)

 Alternatively, it could be that the base TestCase only offers utility
 functions to do certain "set up" and "clean up" tasks and that each test
 class would need to determine what is the most suitable combination for
 those tests.

 More than anything, the base `set_up()` and `tear_down()` methods need
 some very careful scrutiny as they are just doing too much and doing it
 wrong (tear down tasks in set up and visa versa) and for the tests of a
 lot of functions using mostly plain PHP, this amount of set up and tear
 down is just not needed and is detrimental.

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