[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: 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
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|