W3C home > Mailing lists > Public > public-test-infra@w3.org > April to June 2012

Re: Repository layout

From: Robin Berjon <robin@berjon.com>
Date: Tue, 5 Jun 2012 16:05:28 +0200
Cc: James Graham <jgraham@opera.com>, public-test-infra@w3.org
Message-Id: <7F9A6E77-B0BD-48CF-950A-D194BFB666EF@berjon.com>
To: Aryeh Gregor <ayg@aryeh.name>
On Jun 5, 2012, at 10:26 , Aryeh Gregor wrote:
> On Mon, Jun 4, 2012 at 7:35 PM, Robin Berjon <robin@berjon.com> wrote:
>> On Jun 4, 2012, at 18:14 , James Graham wrote:
>>> Yes, but it can *also* mean that you break the test, if you aren't very careful. Consider a test that does document.getElementsByTagName("link")[0], for example.
>> While that is indeed within the realm of possible things, I would like to point out that it is a somewhat contrived example, and easy to fix at that. You would be breaking a broken test.
> Not if the test is actually testing getElementsByTagName.

Not if the test is testing gTBTN *with* the link element. Or if testing the link element. Or if counting the total number of elements in the head or document. I can think of a few more cases, but they're even more contrived :)

I can't avoid noting that we are *already* using (and recommending) metadata inside tests. This is just adding one extra item.

> Better to avoid it and keep the metadata separate.

Note that sidecar metadata containers are entirely possible (and, I believe, already supported) for the tinuscule number of tests that would be affected by this usage. We need those for tests that can't embed metadata as easily for other reasons anyway.

> This is leaving aside the fact that it's quite nontrivial to
> automatically inject an HTML tag in a fashion that's guaranteed to
> parse correctly but also doesn't reserialize the file (which will
> create lots of spurious diffs).

Hmmm, I wasn't thinking of doing this automatically  I was thinking about it being the way to flag a test as broken: add the bug link to it.

Robin Berjon - http://berjon.com/ - @robinberjon
Received on Tuesday, 5 June 2012 14:05:55 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:34:08 UTC