Subject: Re: [xsl] XSLT Unit Testing and Coverage From: "BR Chrisman brchrisman@xxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> Date: Thu, 29 May 2014 07:11:38 -0000 |
On Wed, May 28, 2014 at 10:38 PM, Ihe Onwuka ihe.onwuka@xxxxxxxxx < xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote: > 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 everything needed to test a particular template could be assembled, and the template's name is passed in as initial template... then there's mocking calls like the various input/output doc stuff... and parameters to the template... But it sounds like a lot of the tools out there do this already, like: "show me only the nodes resulting from this template". I can see how that might be useful... all my xslt projects have been implemented as series of small stylesheets applied in a layering/pipeline, so I'd generally achieve mostly the same thing by isolating a template (or a few templates) in a particular layer/stage and using a 'tee' type utility... (works for identity-based transforms). I'm thinking for my next such project, having a stylesheet transform the source stylesheet, adding a debug namespace and instructions to add debug namespace elements to the result nodes of specific templates, so I can track the output of those without having to isolate. > 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. > XSL-List info and archive <http://www.mulberrytech.com/xsl/xsl-list> > EasyUnsubscribe <-list/965995> (by > email <>)
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] XSLT Unit Testing and Cov, Ihe Onwuka ihe.onwuk | Thread | Re: [xsl] XSLT Unit Testing and Cov, Alan Painter alan.pa |
Re: [xsl] XSLT Unit Testing and Cov, Ihe Onwuka ihe.onwuk | Date | Re: [xsl] XSLT Unit Testing and Cov, Alan Painter alan.pa |
Month |