Subject: Re: [xsl] junit test... for xslt2? From: Philip Fearon <pgfearo@xxxxxxxxxxxxxx> Date: Sat, 6 Mar 2010 16:25:07 +0000 |
On Sat, Mar 6, 2010 at 2:46 PM, Tony Graham <Tony.Graham@xxxxxxxxxxxxxxxxxxxxxx> wrote: > On Sat, Mar 06 2010 13:31:03 +0000, pgfearo@xxxxxxxxxxxxxx wrote: > > The issue that I always have with all-XSLT testing frameworks is that > they're good for the feel-good cases of testing that you get the right > output for the right input, but not so good for testing that you get the > right result for the wrong input if the right result is <xsl:message > terminate="yes"/>. > > If the test framework is also XSLT, it's going to die when the > stylesheet under test dies. I can't tell what CoherentWeb would do. > CoherentWeb is essentially just a multi-threaded batch XSLT test harness that iterates through the selected XML test files arranged within a directory structure, performs an XSLT transform and aggregates all results. Any terminations are highlighted as XSLT errors (with a displayed running count) but they're designed in and don't interrupt the batch process. Its probable that the a modified XSPec XSLT implementation would be needed to take full advantage of the way CoherentWeb works. For example, each scenario within a description could be automatically extracted, with context, into a separate test case file and nested scenario files grouped hierarchically within a directory structure. > I'm a committer for both Juxy and XSpec. XSpec is good, and my clients > that are primarily XSLT users prefer it because it's just XSLT, but Juxy > can cope with <xsl:message terminate="yes"> because, as a Java > application with Java and XML syntaxes for tests, it can catch the fact > that the transform terminated and then continue on to the next test. I haven't come accross Juxy, so I will take a look. The sequential nature you describe: waiting for one test to complete before commencing the next, provides the potential for the output of one test to be fed into the input of the next test, at the cost of some performance. Whilst chaining tests in this way could reduce the overhead in setting up the tests I can see some drawbacks also. Regards Phil Fearon http://qutoric.com > > Regards, > > > Tony Graham Tony.Graham@xxxxxxxxxxxxxxxxxxxxxx > Director W3C XSL FO SG Invited Expert > Menteith Consulting Ltd XML Guild member > XML, XSL and XSLT consulting, programming and training > Registered Office: 13 Kelly's Bay Beach, Skerries, Co. Dublin, Ireland > Registered in Ireland - No. 428599 http://www.menteithconsulting.com > -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > xmlroff XSL Formatter http://xmlroff.org > xslide Emacs mode http://www.menteith.com/wiki/xslide > Unicode: A Primer urn:isbn:0-7645-4625-2
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] junit test... for xslt2?, Tony Graham | Thread | Re: [xsl] junit test... for xslt2?, Dave Pawson |
Re: [xsl] junit test... for xslt2?, Tony Graham | Date | Re: [xsl] XSLT for Mashups, Liam R E Quin |
Month |