Re: 28 proposals to improve testcase writing guidelines

Le Mar 6 décembre 2011 14:22, L. David Baron a écrit :
> These seem like 28 proposals to improve test *cases*, but it's not
> clear to me how you intend them to affect the *guidelines*.

David,

Some guidelines in
http://www.w3.org/Style/CSS/Test/guidelines.html
collide with a few of my proposals.

E.g.
"This line should be green."
http://www.w3.org/Style/CSS/Test/guidelines.html#the-green
could mean background or color of a line *of text*.
To my neighbours, "a line" is not even necessarly a line of text but it
could be a line like a math teacher would draw on the black board of a
high school classroom during a geometry course.
To a bus driver, a line is what he sees on both sides of his lane all
day long.
"sentence" is rather consistently clear for everyone (even speaking
different languages, from different cultures) though.


>
> I'd be very hesitant to add 28 rules like these to the guidelines,

There are 2 aspects to my email: I formulate 28 proposals and then I try
to explain them and justify them. I could create a text which would
state those rules in a very good-bad-binary form without explanations...
but then, it would not address the test author's will to cooperate and
intelligence.

> because it makes it much harder for people to get started writing
> testcases, and it makes it harder to convince people that writing
> testcases according to the guidelines is easy to do and worth doing.

I have been able to get 13 web authors to contribute over 100 testcases
to the CSS 2.1 test suite. One key element is that I offered to help
them make their testcases. Maybe you are not aware of

http://www.gtalbot.org/BrowserBugsSection/css21testsuite/web-authors-contributions-css21-testsuite.html


> If they could be boiled down to a few sentences I'd be much happier
> adding to the guidelines.
>
> -David


Some proposals, I feel, are unescapable, unavoidable. Otherwise they
make testcases untrustworthy, difficult to understand, difficult to
figure out, incorrect or unreliable, cause to create more reftests than
needed, possibly necessary to, etc. There are benefits in following
them.

Few sentences? Okay. How about these 4:

1- Try to start all of your tests with the words "Test passes if there
is (are) ..."
2- Don't use "box" or "block" in your pass/fail sentences. Only use one
of the following shape descriptors instead:
rectangle, square, stripe, bar, line, grid.
3- Use "Filler text" for background of tests if needed; use "Text
sample" for tests involving text.
4- Avoid any HTML or CSS vocabulary in the pass/fail sentence.

The rest could be handled by a document called "Perfecting your tests
before submitting them to W3C" and by test case approvers, reviewers.

regards, Gérard
-- 
Contributions to the CSS 2.1 test suite:
http://www.gtalbot.org/BrowserBugsSection/css21testsuite/

CSS 2.1 Test suite RC6, March 23rd 2011:
http://test.csswg.org/suites/css2.1/20110323/html4/toc.html

CSS 2.1 test suite harness:
http://test.csswg.org/harness/

Contributing to to CSS 2.1 test suite:
http://www.gtalbot.org/BrowserBugsSection/css21testsuite/web-authors-contributions-css21-testsuite.html

Received on Tuesday, 6 December 2011 23:49:11 UTC