[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

Re: [xsl] XSLT Unit Testing and Coverage

---

---

On Thu, May 29, 2014 at 3:27 AM, Ihe Onwuka ihe.onwuka@xxxxxxxxx <
xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:

>
> On Thu, May 29, 2014 at 8:11 AM, BR Chrisman brchrisman@xxxxxxxxx <
> xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:
>
>> 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".
>>
>>
> This is why I say it is a big if. My goal in that approach is the
> traceability of the bug to the template, but I would baulk at going so far
> as to isolate execution of that template or to have a framework show me the
> nodes that result, because the quality of my diagnosis may be compromised
> by the morass of information. This is why commercial automated testing
>  tools are a fraud - the problem is not test execution (which is primarily
> what they help with) and hidden in there may be tests that used to pass but
> perhaps no longer should and your framework/test tool isn't going to help
> you with that.
>
> If people could just write code to minimise the incidence of mocking to
> genuine external dependencies (as opposed to self inflicted tight coupling
>  cause by using global variables) then it would also help, but only your
> better programmers will do that. Some of the framework paraphenalia make it
> possible for mediocre programmers to get things done that they may not have
> been able to accomplish before - that is usually seen as a positive from
> the management perspective. Issues relating to technical debt can defer
> ...sometimes that works and sometimes it is disastrous.
>

Reminds me of a pet peeve I have of test frameworks which require code be
written in a certain style that may not be otherwise appropriate (or any
test framework which requires instrumentation in code itself).
Fortunately XSLT lends itself to automation... so creating an nonintrusive
framework seems more easily achievable.
Ideally nobody looks at the code and says "why is it written like that?"
with the answer being "so we can use test tool XYZ".


>
>
>   XSL-List info and archive <http://www.mulberrytech.com/xsl/xsl-list>
> EasyUnsubscribe <-list/965995> (by
> email <>)

---