[wp-trac] [WordPress Trac] #59482: Tests: Introduce Reflection API helper methods.

[WordPress Trac]

#59482: Tests: Introduce Reflection API helper methods.
--------------------------------------+-----------------------
 Reporter:  costdev                   |       Owner:  costdev
     Type:  enhancement               |      Status:  assigned
 Priority:  normal                    |   Milestone:  6.5
Component:  Build/Test Tools          |     Version:
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+-----------------------

Comment (by costdev):

 > @hellofromTonya
 > Naming:
 > `get_reflectionproperty_value()`
 > `set_reflectionproperty_value()`
 > `invoke_reflectionmethod()`

 Sounds good to me!

 > Extending:
 > Statics are handled slightly differently than objects. Might be good to
 extend the API to include statics such as
 `get_static_reflectionproperty_value()`

 Yes this will need some testing and consideration for sure. I agree that
 it makes sense to include it in this API.

 > Resetting:
 > Instantiating and resetting visibility and values with each API method
 call might get too heavy for the test suite performance. Instead, @costdev
 have you considered storing the details and then resetting (visibilities
 and values) at `tear_down()`?

 I did consider this, though I was also mindful of memory usage in the test
 suite (which is additionally worse when running xDebug and coverage
 reports, for example), where storing objects would increase memory usage.
 Based on this, the example implementation in [https://github.com/WordPress
 /wordpress-develop/pull/5338 PR 5338] calls `unset()` on each
 `ReflectionProperty`/`ReflectionMethod` when it's done with them for that
 call.

 I'm not sure whether we're best storing the objects and resetting in
 `tear_down()` when we're definitely done with them to improve timing, or
 calling `unset()` when we're potentially done with them to reduce the
 chance of memory limits being hit on contributor's local machines. There's
 a trade-off either way I think.

 I do wonder if it's possible that we're considering optimization too
 early, and we might be best committing an initial API, then iterating.
 Having this already committed in the Core test suite may make analyzing
 and optimizing its implementation somewhat easier, without having to
 bundle the API and optimization in one PR (or more if we test different
 approaches). What do you think Tonya? Handle it with the initial
 implementation, or iterate when we have more data?

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