- From: Lynne Rosenthal <lynne.rosenthal@nist.gov>
- Date: Wed, 22 Oct 2003 08:24:08 -0400
- To: www-qa-wg@w3.org
All I forwarded Mary Brady, our test development project leader the TCDL proposal yesterday. The following is her comment after a quick review and a brief description of something that we recently started at NIST. The idea here is to have a general test generator (we call test accelerator) that will automatically generate tests. Lynne >X-Sieve: CMU Sieve 2.2 >From: "Mary Brady" <mbrady@nist.gov> >To: <lsr@nist.gov> >Subject: Re: test case description language >Date: Tue, 21 Oct 2003 19:08:44 -0400 >X-Mailer: Microsoft Outlook Express 6.00.2800.1158 >X-MailScanner: > >Hi Lynne, > >This type of thing is what was first developed for DOM. It was thrown out >in favor of something that was more DOM-specific. Essentially, folks are >reluctant to learn things that are different from their working environment. >Initially, we had things like > ><TEST NAME="xxx" method="getElementsByTagName" value="*" > > >and we ended up with something like this instead: > ><getElementsByTagName value="*"> > >I know it's a simple example, but hopefully you see what I'm saying. As we >added >more capability to the first example, it became more and more cumbersome, so >we >redid things to example 2, which was much more straightforward, and allowed >us >to generate a test suite language for DOM directly from the spec. That's >when we >started pursuing automatic generation in earnest => as we tried to get to a >minimal >set that was necessary for a programmer to define, we realized that we could >just >make our code smarter and smarter. > >I've been working individually with each team member this week, and to date, >what >we are shooting for is to build a test accelerator that can handle both >XQuery Expressions >(new XML Query work) and one linux module (tbd) by January. Each >sub-project will >find a way to create an XML Schema that represents the structure of their >language. The >schema will also include calls, variables, datatypes, ranges, and >expressions. Carmelo >and Sandra have been working on this for Query already, and the linux work >had one >already. The user interface will read in this schema, and provide a >mechanism to map >the features in their specific schema to the features that the accelerator >will support. >Then, the user interface will dynamically perform the transformation and >invoke the >accelerator, which will in turn generate the tests, and provide a set of >test assertions >and a test matrix. This approach provides the test writer much more >flexibility, and >doesn't enforce learning a new language -- you'll find as the w3c effort >moves forward, >that the metadata info is straight-forward, but supporting all of the >details of each >specificiation really mangles the language, and makes it incredibly >cumbersome for a >programmer to use. > >If you have any questions, just let me know -- I still have several more >people to meet >with this week, but I'll be checking e-mail in between. I just want to give >you a heads >up on where we are going -- things are beginning to take shape, and I think >it's going >to be pretty exciting. > >--Mary > > >----- Original Message ----- >From: <lsr@nist.gov> >To: <mary.brady@nist.gov> >Sent: Tuesday, October 21, 2003 5:31 PM >Subject: test case description language > > > > > > Hi Mary > > > > FYI - the QAWG will be discussing a Test Case Description Lang - and will >be > > pursuing this over the next year. Dave Marston wrote the original draft >that > > we will be discussing. > > > > http://www.w3.org/QA/WG/2003/10/tcdl-20031012.html > > > > > > --Lynne > >
Received on Wednesday, 22 October 2003 08:30:23 UTC