[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

Re: [xsl] xslt test automation

---

---

Some of the links contained in a similar thread on this list started
byB Dave Pawson onB Mar 6 this year:

http://assets.expectnation.com/15/event/2/Testing%20XSLT%20Presentation.pdf

http://www.proxml.be/users/paul/weblog/fc7ff/Unit_testing_XSLT.html

http://broadcast.oreilly.com/2008/09/xspec.html

CoherentWeb[1] is a rich client app designed from the outset for XSLT
testing, it is commercial software but currently available as a free
Beta.

http://coherentweb.com

only for historical reasons
http://www.fgeorges.org/xslt/xslt-unit/

instead: Go to
http://groups.google.com/group/xspec-users to stay tuned and to
http://xspec.googlecode.com/ to learn more about XSpec.

I hope some of it is useful


On Tue, Nov 30, 2010 at 12:14 PM, Philip Fearon <pgfearo@xxxxxxxxxxxxxx>
wrote:
>
> On Tue, Nov 30, 2010 at 2:18 PM, Dave Pawson <davep@xxxxxxxxxxxxx> wrote:
> > On Tue, 30 Nov 2010 12:04:00 +0000
> > Philip Fearon <pgfearo@xxxxxxxxxxxxxx> wrote:
> >
> >> 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
> >
> > ? Shared with any test environment?
>
> Yes, to be usable on any test environment with the capabilities I
> mention. XPath should be in there somewhere to allow for parameters
> that aren't just xs:string types and to provide the context node. Its
> possible that a subset of XProc (mentioned by @vojtech) would be a
> contender.
>
> > What's being tested (versions ....)
> > When its being tested, who by?
> > Test program (version... parts ...)
> > software in use (xslt engine, java vsn, OS)
>
> This data should be in the summary report, most of it extracted
> automatically, I don't think it all needs to be specified in the input
> environment. The output summary also confirms the input parameters
> etc. that were ultimately used by the test environment, which should
> of course match those specified in the input environment XML.
>
> > Expected output file.
> >
> >
> >> (2) the XML summarising the output
> > Common to any testing?
> No, just to XSLT testing/
> > reference to test definition(s)
> > Test count run
> > Tests passed, failed, not run.
> >
> > Oddity.
> > B templates [matched/named]used
> > B Templates [matched/named] not used.
> > B Input elements not matched (??? If applicable)
> All included in the output summary. Unmatched templates appear as errors
> > B functions used.
> > B XML comparison of expected/actual from each template.... Possible?
> > B  B  B Not sure. How to encapsulate depth? XMLdiff definitely needed.
> Agree XMLdiff would be invaluable for regression testing, but this
> isn't the only kind of test.
> >
> > Overall result.
> > Date/time/operator.
> >
> >
> >
> >>
> >> 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.
> >
> > Define what's wanted first Phil? Defining XML wrappers ins't magic.
> > W3C has a markup IIRC?
> The requirement is that all output data not normally accessible to
> XSLT-based frameworks is collated into a single XML resource, that can
> be.
> >
> >
> >>
> >> 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
> >
> > I'm almost convinced you need more than XSLT to test XSLT properly.
> Well, I guess that depends on how much data the XSLT processor gives you.
>
> > I can't see the GUI coming until testing has been defined?
> Perhaps not for unit testing where you just produce a text-only test
> report. But there are end to end tests or acceptance tests, where
> HTML, Office documents etc are being produced where a GUI becomes
> pretty essential. Not everything can or should be automated and this
> is where a GUI fits in. A command line tool could I guess produce an
> interactive HTML report, but if you're going to end up using a GUI
> (browser) to review test results you might as well start with one.
>
> > I think you'll probably need help from Mike to use Saxon for testing.
> The Saxon API and documentation is pretty extensive, but yes, there
> are times....
>
> > I'm presuming you can't tweak the tested XSLT to test the XSLT... if
> > you see what I mean. That chappie and his cat effect?
>
> I think there's a lot of potential in what you say, there's already a
> capability to use XSLT on the test XSLT to produce the sets of XPath
> used by the GUI for presenting and navigating through specific input
> or output. One of the many benefits of using a declarative language.
> >
> > No, not easy.
> >
> Definitely not!
>
> > --
> >
> > regards
> >
> > --
> > Dave Pawson
> > XSLT XSL-FO FAQ.
> > http://www.dpawson.co.uk
> >
>
> Phil Fearon
> http://qutoric.com

---