W3C home > Mailing lists > Public > www-qa@w3.org > June 2002

Re: Testable assertion tagging for W3C specifications

From: Carmelo <carmelo@nist.gov>
Date: Mon, 3 Jun 2002 11:41:44 -0400
Message-ID: <021601c20b15$2ae90c10$a53b0681@sdct.nist.gov>
To: <www-qa@w3.org>

> If my interpretation of your "add-on tagging" is correct, then an
> addressing scheme I am arguing for can help: One can use
> addresses/citations to identify/extract test assertions or whatever is
> needed to auto-generate a test case. The key here is that the
> addressing scheme is independent from the spec markup and, hence, does
> not require that markup to identify assertions and such. One can use
> the scheme with ASCII text specs, if needed.

     Actually I was thinking more along the lines of a separate XML
     instance, which encapsutes the behavior and data, however there
     is information already in the specs that can be extracted and
     parsed for test generation such as expressions definitions
    (read below).

> Using a good addressing scheme you can create (manually or
> semi-automatically, depending on the quality of spec markup) a set of
> addresses, each corresponding to a test assertion/whatever in the
> spec. Then, you can automatically extract cited spec pieces and apply
> your test case generation engine to them.

    Bear in mind that not all behaviors can be automatically extracted or
    written in a way that a test can be automatically developed for it.  We
    have the issue of parsing the text and attempting to guess the semantics
    of a particular piece of text can be a challenge.

    There are situations where a combination of retrieving text/markup
    from the specs and outside help from XML can be of great benefict
    to develop both the test assertions and the tests. Take for instance the
    definition of a FLWR expression in XQuery:

            FLWRexpr := (ForClause  | LetClause)+whereClause? return Expr.

    This definition can easily be extracted and parsed.  Once parsed, then
    a carefully crafted XML instance can further define values, and data
    sources for the expression as well as ranges, lists etc. This
    can be fed into the test generating engine to develop the actual tests.
    This approach  also allows for easy breath of coverage of certain areas.

Received on Monday, 3 June 2002 11:45:01 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:43:20 UTC