[wp-trac] [WordPress Trac] #53010: Tests: introduce namespacing for the test classes

WordPress Trac noreply at wordpress.org
Mon Sep 23 22:49:43 UTC 2024


#53010: Tests: introduce namespacing for the test classes
-------------------------------------------------+-------------------------
 Reporter:  jrf                                  |       Owner:
                                                 |  hellofromTonya
     Type:  task (blessed)                       |      Status:  assigned
 Priority:  normal                               |   Milestone:  Future
                                                 |  Release
Component:  Build/Test Tools                     |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  2nd-opinion has-patch has-unit-      |     Focuses:  docs,
  tests                                          |  coding-standards
-------------------------------------------------+-------------------------

Comment (by jrf):

 @pbearne To be blunt: every automated patch for this ticket is
 automatically disqualified.

 The whole point of this exercise in the context of #62004 is to have a
 **human** who understands the task at hand:
 * Verify that any existing `@covers` tags are actually correct.
 * Decide based on those `@covers` tags if and if so, how to split the test
 class into multiple classes. Depending on the test class, this could end
 up being a split into dozens of new classes, which will each need careful
 review of what set up/tear down they need, what test case they should
 extend etc.
 * Make sure the `@covers` tags are no longer at method level, but at class
 level.
 * Decide what the right class name should be based on what is actually
 being tested.
 * If there are no `@covers` tags or only partial `@covers` tags (for some
 test methods in a class, not for others), figure out what is ''really''
 being tested (and no, that can't be done based on what function/methods
 are called in the test method, there are a lot more things at play - this
 needs examining the actual code coverage reports and understanding the
 impact of setup/teardown on those, it needs history tracing via `git
 blame` etc).

 Honestly, if I thought, for even a moment, that any form of automation for
 this task would be helpful, I would have written a sniff with an auto-
 fixer for this. The fact that I didn't, should tell you enough.

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


More information about the wp-trac mailing list