Re: [xsl] ANN: 'Testing XSLT' training course PDF available

[Florent Georges <lists@xxxxxxxxxxxx>]

Andrew Welch wrote:

> On 17/12/2007, Tony Graham wrote:

  Hi Andrew,

> > > It's not "unit testing" then... surely?

> > I didn't say that it was unit testing

> We're in agreement then ;) My original comment was only to
> note that you had the black-box testing subheading under
> the main heading of unit testing - which I thought was
> wrong for a document intended to teach people.

> If I said to someone to add some black box tests and they
> wrote a load of unit tests, I wouldn't be very
> happy... (especially if they'd just come back from a
> course on testing)

> Just because some "XSLT unit test frameworks" can operate
> at the transform level, it doesn't suddenly alter the
> meaning of the terms involved.

  I must admit I don't really understand this black box /
white box discussion about unit testing.  Unit tests (as
almost everytime we are speaking about tests) are black box
tests.  Unit testing is about testing little (sometimes not
so little) units of code (whatever you call them classes,
template rules, functions, components or modules, Gerard
Meszaros uses instead SUT, system under test).  But without
depending on the implementation of the unit itself, only on
its interface, its purpose (not its behaviour).

  Of course, unit testing goes into the details of program,
because tested units can be internal units.  But that's only
a matter of level within the program.

  For instance (and to be on topic), you can test a template
rule that transforms a list-like element to HTML, without
looking at *how* it works.  You only assert that the result
is for example a UL element, with the appropriate @class:

    <t:test>
       <t:title>My "list" template rule</t:title>
       <!-- the fixture -->
       <xsl:variable name="input" as="element()">
          <list>
	     <item><link target="..."/></item>
	     <item><picture file="..."/></item>
          </list>
       </xsl:variable>
       <!-- exercize the unit, the SUT -->
       <xsl:apply-templates select="$input" t:variable="result"/>
       <!-- assertions -->
       <t:assert-true select="$result instance of element(h:ul)"/>
       <t:assert-eq expect="'list-class'" select="$result/@class"/>
       <t:assert-eq expect="2" select="count($result/*)"/>
    </t:test>

  The fact that the LINK is actually transformed into an A
element and the PICTURE into an IMG is checked somewhere
else, in the appropriate unit test.  This is particulary
useful when you use the Standard Fixture Pattern and you
create a set of representative real inputs for your tests.

  Did I miss something?

  PS: Some of the terms here have been shamefully stolen
from the book "XUnit Test Patterns--Refactoring Test Code"
by Gerard Meszaros: http://xunitpatterns.com/.  Great book
for those interested in the subject (and for any developer).

  Regards,

--drkm





















      _____________________________________________________________________________ 
Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail http://mail.yahoo.fr