- From: Robin Berjon <robin@w3.org>
- Date: Thu, 07 Feb 2013 11:34:58 +0100
- To: James Graham <jgraham@opera.com>
- CC: public-html-testsuite@w3.org
On 07/02/2013 10:24 , James Graham wrote:
> On 02/07/2013 09:55 AM, Robin Berjon wrote:
>> I would really rather not. Metadata capture should be designed in such a
>> way that it ensures in as much as possible that it won't go out of date.
>> External authoritative metadata such as in a text file is guaranteed to
>> break. That's why I proposed inlining it (in the most lightweight manner
>> I could think of).
>
> Inline metadata has the disadvantage that it is hard to extract
> (requires a HTML parser in this case)
Dirty secret: I was thinking that:
fs.readFileSync("test.html", "utf8).match(/\ddata-manual\b/)
would do the trick :)
> and can affect the test itself.
It could, I guess, if the implementation does something really weird (or
you're doing a manual test that enumerates stuff on <html>, which I
would likely frown upon).
>> Another option is to capture that in file names (if there's ".manual."
>> in the file name, then it's manual).
>
> That option works for me, as long as "javascript" is considered the
> default.
Well of course.
I can live with using the file name (a convention that we can extend to
reftests as well). I don't have a strong preference between that and
inlining but since you do I'll go with the flow. Anyone disagrees?
> Alternatively I am happy with a specific sub-directory for non
> automated tests
We use directories to map to spec sections — I'd rather keep it that way.
--
Robin Berjon - http://berjon.com/ - @robinberjon
Received on Thursday, 7 February 2013 10:35:06 UTC