[wp-trac] [WordPress Trac] #60227: HTML API: Add external test suite

[WordPress Trac]

#60227: HTML API: Add external test suite
--------------------------------------+---------------------
 Reporter:  jonsurrell                |       Owner:  (none)
     Type:  enhancement               |      Status:  new
 Priority:  normal                    |   Milestone:  6.5
Component:  Build/Test Tools          |     Version:
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+---------------------

Comment (by dmsnell):

 > What would folks think of setting these as not being loaded and then run
 separately as is done with the HTTP remote and ajax tests. I think since
 these tests will never interact with the Database or work differently with
 multisite, we can also keep the matrix fairly small.

 To me this seems like a perfectly reasonable solution. It would be great
 having them in the code so we don't have to constantly merge and revert
 merges on our dev boxes, plus having them there for anyone to use would be
 useful. Apart from relying on `esc_attr()` and `_doing_it_wrong()` the
 HTML API is also essentially independent code, so running in a separate
 runner is also fine.

 > put the checks for if something should be in the dataProvidor inside the
 generator and only yield it if it should be tested

 Technically this should be possible, but it would imply running the tests
 at least twice. A hard part about this is that we don't know up-front
 whether a test should be run or not. Literally the determination is
 whether the HTML Processor gets through the input document without bailing
 because of unsupported markup. We //could// theoretically manually scan
 through the thousands of tests and skip ones we know can't run, but then
 we'd have to manually sort those skips tests every time we make a change
 to the API code and I'm sure we'd simply end up missing tests that need to
 be included.

 The way we could do it is run the parser over the input in the data
 provider, and if it finishes then return it for the test proper, otherwise
 omit it. I can predict some valid critique of doing this, but it's
 definitely an approach we could take.

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