[wp-trac] [WordPress Trac] #54177: Add visibility to test class methods

[WordPress Trac]

#54177: Add visibility to test class methods
--------------------------------------+-------------------------------
 Reporter:  costdev                   |       Owner:  (none)
     Type:  enhancement               |      Status:  new
 Priority:  normal                    |   Milestone:  Awaiting Review
Component:  Build/Test Tools          |     Version:
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:  coding-standards
--------------------------------------+-------------------------------

Comment (by costdev):

 Regarding the coding standards point, I see that relevant rules were
 implemented in the `WordPress-Extra` ruleset as a result of
 [https://github.com/WordPress/WordPress-Coding-Standards/issues/1101 this
 issue].

 These rules are specifically related to this ticket:

 {{{#!xml
         <rule ref="Squiz.Scope.MethodScope"/>
         <rule ref="Squiz.WhiteSpace.ScopeKeywordSpacing"/>
 }}}

 Given that this ticket aims to resolve missing scope, it would be a shame
 to miss the opportunity to move these into the `WordPress-Core` ruleset,
 targeting the `tests/phpunit/tests/` directory, so that we don't have to
 repeat this task in future.

 Similar to this (with some review of the paths):

 {{{#!xml


         <!-- Exclude some directories from scope sniffs. -->
         <rule ref="Squiz.Scope.MethodScope">
                 <exclude-pattern>/src/*</exclude-pattern>
                 <exclude-pattern>/build/*</exclude-pattern>
                 <exclude-pattern>/node_modules/*</exclude-pattern>
                 <exclude-pattern>/vendor/*</exclude-pattern>
                 <exclude-pattern>/tools/*</exclude-pattern>
                 <exclude-pattern>/tests/e2e/*</exclude-pattern>
                 <exclude-pattern>/tests/gutenberg/*</exclude-pattern>
                 <exclude-pattern>/tests/qunit/*</exclude-pattern>
                 <exclude-pattern>/tests/phpunit/build/*</exclude-pattern>
                 <exclude-pattern>/tests/phpunit/data/*</exclude-pattern>
                 <exclude-pattern>/tests/phpunit/includes/*</exclude-
 pattern>
         </rule>
         <rule ref="Squiz.WhiteSpace.ScopeKeywordSpacing">
                 <exclude-pattern>/src/*</exclude-pattern>
                 <exclude-pattern>/build/*</exclude-pattern>
                 <exclude-pattern>/node_modules/*</exclude-pattern>
                 <exclude-pattern>/vendor/*</exclude-pattern>
                 <exclude-pattern>/tools/*</exclude-pattern>
                 <exclude-pattern>/tests/e2e/*</exclude-pattern>
                 <exclude-pattern>/tests/gutenberg/*</exclude-pattern>
                 <exclude-pattern>/tests/qunit/*</exclude-pattern>
                 <exclude-pattern>/tests/phpunit/build/*</exclude-pattern>
                 <exclude-pattern>/tests/phpunit/data/*</exclude-pattern>
                 <exclude-pattern>/tests/phpunit/includes/*</exclude-
 pattern>
         </rule>

 }}}


 ----

 If there's a desire to extend this for the whole of core, I'm happy to:

 1. open an additional ticket (so that this one is essentially a dry-run
 for core) and get started with running `phpcs`.
 2. add scope from `private` to `protected` to `public` until all tests
 pass.
 3. open a PR when this is ready for review.

 Assumptions:
 - We'd need to update the GitHub actions at the same time as merging the
 change.
 - A re-run of GitHub actions would possibly need to be forced on open PRs
 at the same time so that all of these can be updated before being merged.
 - A core merge is best done just after a major release.

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