- From: Alan Stearns <stearns@adobe.com>
- Date: Mon, 16 Jan 2012 11:42:52 -0800
- To: "Linss, Peter" <peter.linss@hp.com>, Robin Berjon <robin@berjon.com>
- CC: public-test-infra <public-test-infra@w3.org>
On 1/16/12 11:24 AM, "Linss, Peter" <peter.linss@hp.com> wrote: > On Jan 16, 2012, at 7:28 AM, Robin Berjon wrote: > >> On Jan 11, 2012, at 17:38 , Linss, Peter wrote: >> >>> the assertion should not be the name of the test, but rather a list of the >>> assertions in the specification tested. >>> Also, a planned augmentation is to allow the spec links to point to any >>> anchor in the spec to allow narrower targeting of testable assertions. this >>> will go hand in hand with additional markup in the spec to identify those >>> assertions in an automated way. >> >> Yes, I was thinking about markup as used in the test meth document. I'm >> guessing that instead of assertions there could be assertion-links (or we >> could overload and guess). > > Fantasai and Alan Stearns have had a long discussion about how best to markup > specs in a manner that testable assertions can be found by automated tools. > I'm not sure if what they came up with has been documented anywhere yet. I wrote down what we're planning on doing for CSS Regions tests on the spec wiki page: http://wiki.csswg.org/spec/css3-regions#spec-and-test-metadata The main idea is that tests can link to any anchor in the spec, and non-testable anchors will get a new "informative" class attribute. Then the spec can be scanned for all non-informative anchors to discover whether there are corresponding tests. Thanks, Alan
Received on Monday, 16 January 2012 19:43:25 UTC