[wp-trac] [WordPress Trac] #21271: Make admin backend unit-tests friendly

[WordPress Trac]

#21271: Make admin backend unit-tests friendly
-------------------------------+-----------------------------
 Reporter:  sirzooro           |       Owner:
     Type:  enhancement        |      Status:  new
 Priority:  normal             |   Milestone:  Future Release
Component:  Build/Test Tools   |     Version:  3.4.1
 Severity:  normal             |  Resolution:
 Keywords:  needs-patch close  |     Focuses:  administration
-------------------------------+-----------------------------
Changes (by bpetty):

 * keywords:  needs-patch dev-feedback => needs-patch close


Comment:

 Personally, I think this generally just involves modularizing each
 individual functional component/responsibility into more general (and
 reusable) admin APIs like `WP_Screen`. Each one of those components will
 have their own back-compat issues to deal with, and will each need to be
 considered individually anyway as their respective API designs are
 discussed, tested, approved, and finally applied. I think this is
 something everyone has already been doing as we identify the best
 potential areas that can/should be addressed at that given moment. This
 has always just been an ongoing task, and we don't need a ticket to track
 a continuous task involving a general programming practice.

 You did suggest a specific global approach though, so let me address that.

 * Actually including the admin PHP endpoint files themselves just makes
 them significantly more complex and not only changes the environment in
 which they run (something unit tests should avoid when possible), but
 might not even be possible for certain admin pages, and likely
 incompatible with numerous plugins which often won't be expecting to be
 buffered.
 * This also encourages (as you did yourself) extremely volatile assertions
 based on content being returned from the output buffer, and this is a
 specifically discouraged practice when writing unit tests. We need to be
 writing tests against the functionality of specific individual methods,
 which is both more reliable, but also more helpful in isolating and
 identifying broken behaviors.
 * PHPUnit contains it's own [http://phpunit.de/manual/current/en/writing-
 tests-for-phpunit.html#writing-tests-for-phpunit.output output buffering
 functionality] that we don't need to duplicate or interfere with, but even
 using that isn't encouraged: "A test that emits output will fail in strict
 mode."

 The output buffer will frequently change significantly in unpredictable
 ways, but in ways that remain perfectly functional without actually
 breaking anything. Unit tests can't account for that in any efficient
 manner, this would require rewriting those unit tests every time some
 content is moved around a bit. This is why it's referred to as "units of
 code", functionality that is being tested needs to be as isolated as
 possible from external environmental factors.

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