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

Re: XSLT Unit Testing and Coverage

Subject: Re: XSLT Unit Testing and Coverage
From: "Ihe Onwuka ihe.onwuka@xxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>
Date: Thu, 29 May 2014 05:37:58 -0000
Re:  XSLT Unit Testing and Coverage
On Wed, May 28, 2014 at 8:38 PM, Ihe Onwuka <ihe.onwuka@xxxxxxxxx> wrote:

> On Wed, May 28, 2014 at 7:57 PM, Vasudev Kandhadai
> vasu.kandhadai@xxxxxxxxx <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:
>> Dear All,
>> is there a good reason to deploy a XSLT unit testing framework?
> No.
>> I have never seen any serious XSLT dev env where the XSLT unit testing
>> was either done religiously, or considered mandatory.  Other than a very
>> religious Java development team with strict Junit set up with Maven etc,
>> who have adopted XSLT into their dev env, who would now want to extend the
>> same ideologies to the XSLT world?  I have personally never used or
>> utilized practically any XSLT unit testing framework in any project and nor
>> was there any requirement to do so...
> Why is Java a valid reference point. It's a completely different language.
Right. This merits amplification. The phrase "Unit Test Frameworks"  has
acquired in my view a specific connotation related to ideas from Test
Driven Development. They are a creature that evolved from the procedural
programming community to solve problems that arise during the development
of procedural programs.

XSLT done right is declarative. The programmer does not have the same level
of control over what processing (and therefore what tests) gets done when.
So before adopting a methodology founded on "Unit testing frameworks" the
first question I would ask is - in XSLT what should constitute a unit - or
to put it more finely what is the smallest component that should be the
subject of a discrete testing effort.

Is it a stylesheet. I don't think so, at least not if you are coding
declaratively. How would I think about it. Well what is more useful on a
bug report - that there is a bug on stylesheet X, or that  executing tests
targeted at template Y in stylesheet X exposed a bug.  So I would say the
focus on testing an XSLT program should be at the template rule level and
if I were to adopt any sort of test driven methodology it might evolve
around the concept of the template rule as a unit (with all that entails).
 That however is  a big if.

 If someone were to sit down and design from scratch a testing methodology
acclimated to XSLT in particular and declarative programming in general it
would not look like nUnit. The efficacy of these testing methodologies is
oversold. Similar benefits would accrue to any effort that entailed the
automation of test execution. What nUnit has done is increase the number of
programmers that are willing to be involved in testing by turning it into a
programming activity and that has a knock on beneficial effect especially
in the paradigm from which these methods evolved.

Current Thread


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.
First Name
Last Name
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.