- From: <bugzilla@jessica.w3.org>
- Date: Mon, 05 Dec 2011 19:49:03 +0000
- To: public-test-infra@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15062 --- Comment #2 from Richard Ishida <ishida@w3.org> 2011-12-05 19:49:02 UTC --- Thanks for clarifying that we need to avoid potential clashes when using tests in other test suites. I'll revisit the i18n naming policy to try to ensure that this is the case. I guess I'm not fully clear about what constitutes a 'unique' test, and what the best course of action is for the tests in question. I can see a couple of possibilities. The tests in question test exactly the same assertion, it's just that the test itself is served up in different syntax, depending on whether this is the html4, html5, xhtml1.0(html), xhtml1.0(xml), xhtml5 or xhtml1.1 test suite. (There are some tests that are not relevant in some formats, or are only relevant as exploratory tests. If a test is not relevant to a format, it is not included in a the test suite for that format. These conditions tend to occur in tests of character encoding declarations, language decls, etc. that use different markup depending on the format. For an example of how tests map to formats differently you can see http://www.w3.org/International/tests/html-css/list-encoding. My concern here is with tests that *are* relevant in more than one format.) I could create ids so that each test suite only shows the results of tests in that particular format. On the other hand, i could allow results to accumulate, as they currently do, if they are testing the same thing. In this case, however, it would be desirable to be able to tell which test relates to which format. I assume that this is dependent on the "proper version information" in the manifest. My question is, what version information is that, specifically? Is it the format field? How do i distinguish between html4 vs html5 tests? -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
Received on Monday, 5 December 2011 19:49:06 UTC