Re: Initial CSS Regions tests submitted

Le Lun 24 octobre 2011 22:33, Alan Stearns a écrit :
> Hey all,
> I just submitted 14 self-describing reftests for CSS Regions. These
are
> just
> the beginning - most are -001 tests for categories that will need
quite
> a
> few numbers added to the test sequence. Since I'm new to CSS testing, I'd
> appreciate any time any of you can take to give me feedback on making
these
> tests better.

> You can see the test list here:
> http://test.csswg.org/shepherd/search/author/astearns/


Alan, here's my feedback.

1- You need to create a support folder in your contributor directory so
that images can be loaded.
http://test.csswg.org/source/contributors/adobe/submitted/regions/flow-from-content-property-001.xht
will not fetch
support/1x1-red.png


2-
http://test.csswg.org/source/contributors/adobe/submitted/regions/flow-into-invalid-names-001-ref.xht
a class region is declared and defined but never used

http://test.csswg.org/source/contributors/adobe/submitted/regions/region-overflow-001-ref.xht
class break is used but never declared nor defined;
.rightSide is declared and defined but never used

Maybe this is not very important since these are reftests.


3- There is no format requirement stating this (although there is a
review checkpoint about it [1]) but most tests start at the top with a
<p> stating the pass/fail condition of the test and then the test itself
follows. Since we read from left to right and then from top to bottom,
the
reading order embrases or should embrase the flow of the test. In my own
tests, I usually remove "after this line", "below", "following", "after
this paragraph" which are pretty much self-descriptive, auto-logical,
self-sensical-sensible, self-explanatory.

If you put the pass/fail condition sentence of the test after the test
itself, then you have to carry "above" words, meaning, references and
identify the parts of the test above, sometimes with difficulties
(imagine explaining that the test passes if blue square is below the
green one which are above the pass/fail condition sentence).

In some tests, you embed the pass/fail condition sentence of the test in
the test itself: I do not feel this is correct for various reasons.

Another thing most of us do is to use <p> for the pass/fail condition of
the test and then try to restrict <div> and <span> for the test itself
in order to avoid unforeseen side effects.


4- In my opinion, it is often preferable to set the line-height to be a
scale factor of the font-size; and, generally speaking, font-size in
relative units should be preferred ... so that everything is
text-size-resizable and font-size-independent. The scaling factor for
line-height should be chosen such that the leading can be split into 2
halves
without creating fractional pixel, at least, with the initial body
font-size.

One of the uncommon assumption [2] for testcases is that the default
font-size is medium, which is 16px. So, unless there is something
particular about a specific testcase, your testcases do not need to set
such font-size.

There are testcases or code situations where line-height should be set
because browser defaults are not the same. Firefox's 'line-height:
normal' computes to 1.2 whereas other browsers, it is 1.0. If your
testcases require to control the line-height with pixel precision, then
I suggest

body {font-size: 1em; line-height: 1.25;}

The possible problem with 'line-height: 19px' is that top-half-leading
and bottom-half-leading will not be equal regardless of font type used.

5- Generally speaking, the ideal testcases are written so that
non-web-expert people (your neighbour, your bus driver, a taxi cab
driver) can do whole test suites without problems, without asking
questions, without thinking or hesitating on a testcase.


6- Meaningful shape descriptors

I recommend to absolutely remove all occurences of "box" everywhere in
your tests; a real box is a 3 dimensional object. A {square, rectangle,
etc} is a much better descriptive geometrical shape for your testcases
and for all testcases.

Ideal shape descriptors for testcases are: square, rectangle, stripe,
bar, line, grid.

Sometimes, if this is part of the testcase pass condition, you may have
to describe furthermore such geometrical shape: a filled green square, a
hollow rectangle, a thick vertical blue line, a sentence with italic
formating, etc.

7- Technical terms: to avoid

It is better to avoid expressions like "after|before|below this div"
(eg
http://test.csswg.org/source/contributors/adobe/submitted/regions/flow-content-002.xht
)
and "19px gap"
(eg
http://test.csswg.org/source/contributors/adobe/submitted/regions/flow-into-001.xht
)
that I've seen in a few of your tests. Again, ideally, any normal person
(your neighbour, your bus driver, your taxi cab driver) should be able
to check testcases without difficulties or hesitation.

In that sense,
"with invalid flow names" from
http://test.csswg.org/source/contributors/adobe/submitted/regions/flow-into-invalid-names-001.xht
is definitely too technical for lots of people not familiar with CSS
regions.


7- Unneeded, unnecessary, unimportant words in pass conditions:
"visible", "on the page", "in the page", "display", "appear", "if this
text is displayed", "if you see", etc.

One implicit but obvious assumption is that the tester should not be
blind. So,

"Test passes if there is no red visible on the page."
can safely become
"Test passes if there is no red."

and

<div class="error">FAIL if this text is displayed.</div>
can safely be replaced with
<div class="error">FAIL</div>

One non-stated goal of all testcases is to reduce the amount of reading
without compromising clarity; this is furthermore important if a test
suite has hundreds of tests.

8- One way to help testers and speed up checking is to focus on the most
important pass conditions of a test and then embolden the words for it,
describing it in order to increase/help eye scannability and to
trigger/help text skimmability, the tester's vigilance, concentration on
a particular aspect of the whole page. This is going to be appreciated
by testers who have to go through hundreds/thousands of tests in a
single day.

Good words to embolden:
"no red"
"same width"
"equal height"
"filled green square"
""1 2 3" in order"
"on the left"
"aligned at the top"
etc.

9- Semantically speaking, I think your tests misuse class attribute and
id attribute. Class is for styling logical group of elements; id is for
unique element in a page.


10- In
http://test.csswg.org/source/contributors/adobe/submitted/regions/flow-into-001.xht

           .region{
line 19:   width: 100%;
           height: 20px;
           }

I'm not familiar with CSS regions but, in that testcase, is there a need
to declare 'width: 100%' ? Same question with a few other testcases.

11-

> Most of the tests are showing as "Needs Work" because I used spec
links
> to the current editor's draft of CSS Regions.

In the specification <link>s, if you know the section and title of that
section, then it helps to identify it. Some browsers with advanced site
navigation toolbar will display such info.

E.g.:

<link rel="help"
href="http://www.w3.org/TR/css3-regions/#the-content-property"
title="3.2. The 'content' property" />

is a bit more convenient than

<link rel="help"
href="http://www.w3.org/TR/css3-regions/#the-content-property" />

for those people using such browsers.



[1]:
"
Test instructions are in <p>.
Test uses only <div>, <span>, and <p> unless testing interactions with
other elements.
"
Test Contents
http://wiki.csswg.org/test/css2.1/review-checklist#test-contents

[2]:
[RC6] CSS 2.1 Test suite, Uncommon Assumptions
http://test.csswg.org/suites/css2.1/20110323/#uncommon

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, 25 October 2011 20:57:34 UTC