W3C home > Mailing lists > Public > public-css-testsuite@w3.org > November 2016

Reftest chains and cycles

From: Geoffrey Sneddon <me@gsnedders.com>
Date: Wed, 16 Nov 2016 14:47:34 +0000
Message-ID: <CAHKdfMgcP5PBT=D_8Wze9478+oczeQHz-h8yNjJWP2MF3Xz2SQ@mail.gmail.com>
To: public-test-infra <public-test-infra@w3.org>
(Bcc'd public-css-testsuite; given we previously decided to unify this
and we're soon merging into web-platform-tests, let's handle
everything on public-test-infra)

For background, see [0].

At the moment, we don't disallow cycles. Until recently, the
documentation recommended them (pretty sure my removing that was
accidental, given I think in principle the CSS WG still prefers them,
though see the below!).

Presently, web-platform-tests has none (okay, it has one self-loop!)
after we removed them a couple of months ago (there were only eight,
all by one author… and far more self-loops).

csswg-test has these[1] cycles; they mostly contain only two nodes,
except for the one self-loop. The majority of these are two related
refs pointing to each other, which seems reasonable enough; there's
also a bunch of tests that just point at each other[2], which is
entirely ineffectual (they'll either both pass or neither pass, after
all!). As such, I think we should ban cycles containing tests. (This
is strictly harsher than we need, but I don't think there's any
disadvantage to this, given we've never actually done what the
documentation recommended, and was never really feasible.)

I don't think I really need to say much about self-loops: they're
either tautologies or contradiction, depending on whether they're
match or mismatch refs, so they're totally useless and should be

See [3] for a list of all edges in the reftest graph that point at
somewhere that doesn't look like a reference (again, w-p-t has none of
these). Most of these are what we expect from the cycles, along with a
bunch of tests pointing at: support/reftest-border-image-5.png,
support/pass.xht, or blank.html. (We only consider files in /reftest/
or /reference/ to universally be references, not support, though that
does disqualify them from being tests.)

The only particularly notable thing in that is we have a test pointing
to another test as a reference:
/css-transforms-1/transform3d-perspective-origin-001.html points to
/css-transforms-1/transform3d-rotatex-perspective-001.html—but that
graph is largely non-sensical (see reachable.png, attached; remember
that multiple outgoing edges from a node are *alternates*, and as such
you can remove the edges to transform3d-rotatex-perspective-001.html
and transform3d-rotatex-ref.html without actually changing the pass
condition of the suite!).

Another interesting case we had until recently was having
at-charset-002, -003, etc. pointing at -001, which pointed to
-001-ref. Them pointing to -001 wasn't actually testing anything,
hence they now all point at -001-ref directly.

As such, the only cases we have of tests being references are pretty
nonsensical: we have a bunch which are all cycles (i.e., two
equivalent tests), and we have a test which partakes in a graph where
half the alternates are semantically equivalent. Is there any case
where someone actually wants to write a test that points to another
test which actually increases coverage of the testsuite? Notably,
test_a.html -> test_b.html -> ref_b.html provides identical coverage
to test_a.html -> ref_b.html and test_b.html -> ref_b.html (because we
can infer that test_a == test_b if both pass).

If not, I think we should require all resources at match/mismatch URLs
(of either a test or a ref) to be refs, which also means we don't need
any rules about filenames (except for enforcing this!) as tests are
just the source nodes in the graph.

Thoughts/opinions on any of the above, plz and thx.


[0]: https://lists.w3.org/Archives/Public/public-test-infra/2015JanMar/0016.html
[1]: https://gist.github.com/gsnedders/b52b5c2ae48f9f70beabe858003b352c
[2]: https://github.com/w3c/csswg-test/issues/1127
[3]: https://gist.github.com/gsnedders/fad6a1fa677cc627817c2d3b772ae1d1

(image/png attachment: reachable.png)

Received on Wednesday, 16 November 2016 14:48:11 UTC

This archive was generated by hypermail 2.4.0 : Friday, 20 January 2023 19:58:22 UTC