One of the common use cases of unittests in my experience is to drill down
into a stack of code and isolate a bug.  The unittests are often kind of
'leftovers'.
There are probably some styles of XSLT work that would work with that, but
not generally how I personally work in XSLT.
More of a fan of end-to-end testing and differential stuff.


On Wed, May 28, 2014 at 11:57 AM, Vasudev Kandhadai vasu.kandhadai@xxxxxxxxx
<xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:

> Dear All,
> is there a good reason to deploy a XSLT unit testing framework? 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...
>
> So considering we need to do this, I came across,
> XSPEC, XUnit etc.. Xspec seems like a good one,  but doesnt look like a
> lot of discussions are  happening in the community.. The Coverage feature
> doesnt work ...
> The class is not being maintained.
>
> Cakupan, was very hard on my brains to read the manual.. Again something
> that has been out there for a while and not sure it is still maintained /
> supported.
>
> Does anyone has any ideas on what options we have in the XML world for
> XSL Unit Testing + Coverage Report
>
> I tried posting to the Xspec community but no one bothered to answer my
> questions , so I am inclined to think it is dead.
>
> Somehow I am also inclined to think Coverage feature is a very
> Java/C#/C/C++ paradigm... Doesnt make too much sense with the XSLT world?
>
> Your inputs are valuable.
> Kandha.
>   XSL-List info and archive <http://www.mulberrytech.com/xsl/xsl-list>
> EasyUnsubscribe <-list/965995> (by
> email <>)