- From: Robin Berjon <robin@berjon.com>
- Date: Tue, 5 Jun 2012 16:05:28 +0200
- To: Aryeh Gregor <ayg@aryeh.name>
- Cc: James Graham <jgraham@opera.com>, public-test-infra@w3.org
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