[wp-trac] [WordPress Trac] #21271: Make admin backend unit-tests friendly
WordPress Trac
noreply at wordpress.org
Wed Feb 19 02:36:01 UTC 2014
#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
More information about the wp-trac
mailing list