Re: [xsl] xslt test automation

Subject: Re: [xsl] xslt test automation
From: Philip Fearon <pgfearo@xxxxxxxxxxxxxx>
Date: Tue, 30 Nov 2010 12:04:00 +0000
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