[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: xslt test automation

Subject: Re: xslt test automation
From: Philip Fearon <pgfearo@xxxxxxxxxxxxxx>
Date: Tue, 30 Nov 2010 12:04:00 +0000
Re:  xslt test automation
Just to follow on from Wendell, to speak up as a vendor whose main
product is best described as an XSLT tool optimised for testing:

I think that, with XSLT being declarative, many developers decide not
to simply port test methodologies that are probably best suited for
imperative code anyway.

My company's approach is to let the developer/tester decide on the
specifics on how they manage their XSLT test cases. The aim is to
provide a set of features suitable for general XSLT processing, but
specially enhanced for testing:

1. A test file management system that caters for tests managed in a
folder hierarchy
2. An input environment manager for setting:
       a. XSLT parameters
       b. target template
       3. mode
       4. context node
3. An XPath development environment for:
       a. Developing a set of 'watch' expressions to review/compare output
       b. Maintaining expression files, and their evaluation context -
used for controlling the input environment (see: 2)
4. A multi-threaded harness for the XSLT processor
5. Real time feedback on test progress
6. Resource management for DTDs, XSDs, but also for XML/non-XML files
etc referenced by either the test input or output
7. Output management for exporting test results in a folder structure
mirroring the input
8. Background deletion of previous tests file
9..An XML report summarising ALL test output including:
    a. principle output details
    b. errors
    c. xsl:message output details
    d  xsl:result-document output details

With the above, there are possibly 2 areas where it would be useful to
have some kind of community standard:
(1) the XML for expressing the test input environment
(2) the XML summarising the output

I've previously appealed for views on a common format for the XML
output summary but this wasn't met with enthusiasm at the time.

So, I'm afraid that, as yet, my company provides no framework that you
can run from the command line, this is all managed from a GUI. Its
kind of like an IDE, but with multi-column file lists intended for
reviewing the large set of files that comprise a test suite, instead
of the more conventional tabbed pages, which require you to first open
a file to view it. - Tabbed pages are used, but only to let you switch
between associated input, output and the XSLT.

Phil Fearon
http://qutoric.com

On Mon, Nov 29, 2010 at 11:02 PM, Wendell Piez <wapiez@xxxxxxxxxxxxxxxx>
wrote:
> Bernhard,
>
> At 11:02 AM 11/24/2010, you wrote:
>>
>> I'm wondering how you test your xslt stylesheets.
>>
>> I've found a few projects addressing this, for example:
>> http://xspec.googlecode.com/
>> http://utf-x.sourceforge.net/
>>
>> But most of these tools seem to be abandoned or their mailing list low
>> traffic. I wonder why that may be:
>> Isn't it very common to develop an xslt and then refactor it? Wouldn't a
>> test suite help in this situation? How about test driven development?
>
> My guess is that the reasons for slow development of XSLT testing
frameworks
> in open-source community-driven projects have little or nothing to do with
> the need, as such. That is, yes, it's common to refactor XSLT; yes, a test
> suite helps (and at other times too). But the fact that there is a need is
> not in itself a sufficient motivation for development.
>
> In particular, the people who would be best qualified to define the needs
> and requirements are not necessarily the ones who are best able to
> accomplish the development itself -- this notwithstanding the fact that
XSLT
> is often an excellent tool for solving the problems of XSLT developers --
> either because we don't have the necessary skills at lower-level software
> engineering, or (just as bad if not worse) we don't have the time.
>
> This makes me wonder whether rather than look for this development to
happen
> in the community at large, we shouldn't be encouraging our tools vendors to
> be taking this work further. It is worth paying money for. A good testing
> framework can certainly pay for itself.
>
> Cheers,
> Wendell
>
>
>
> ======================================================================
> Wendell Piez                            mailto:wapiez@xxxxxxxxxxxxxxxx
> Mulberry Technologies, Inc.                http://www.mulberrytech.com
> 17 West Jefferson Street                    Direct Phone: 301/315-9635
> Suite 207                                          Phone: 301/315-9631
> Rockville, MD  20850                                 Fax: 301/315-8285
> ----------------------------------------------------------------------
>  Mulberry Technologies: A Consultancy Specializing in SGML and XML
> ======================================================================

Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.