xsl-list
[Top] [All Lists]

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

2007-12-18 06:32:32
Hi Andrew,
   Though how you define black and white box testing as it relates to
unit tests is correct in most of the scenarios, IMHO, unit tests can
be both black box as well as white box. Just that while thinking of
unit tests as black box, the unit or the box is small.

On Dec 18, 2007 6:27 PM, Andrew Welch 
<andrew(_dot_)j(_dot_)welch(_at_)gmail(_dot_)com> wrote:
On 18/12/2007, Florent Georges <lists(_at_)fgeorges(_dot_)org> wrote:
  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.

Hi Florent - I know what you mean (see below) but I'm afraid that's wrong :)

Consider the sudoku solver:

http://andrewjwelch.com/code/xslt/sudoku/sudoku-solver.html

Black box testing is to run the transform with a given input, such as
"Al Escargot":

1,0,0, 0,0,7, 0,9,0,
0,3,0, 0,2,0, 0,0,8,
0,0,9, 6,0,0, 5,0,0,

0,0,5, 3,0,0, 9,0,0,
0,1,0, 0,8,0, 0,0,2,
6,0,0, 0,0,4, 0,0,0,

3,0,0, 0,0,0, 0,1,0,
0,4,0, 0,0,0, 0,0,7,
0,0,7, 0,0,0, 3,0,0

and check that the result matches what you expect:

1, 6, 2,   8, 5, 7,   4, 9, 3,
5, 3, 4,   1, 2, 9,   6, 7, 8,
7, 8, 9,   6, 4, 3,   5, 2, 1,

4, 7, 5,   3, 1, 2,   9, 8, 6,
9, 1, 3,   5, 8, 6,   7, 4, 2,
6, 2, 8,   7, 9, 4,   1, 3, 5,

3, 5, 6,   4, 7, 8,   2, 1, 9,
2, 4, 1,   9, 3, 5,   8, 6, 7,
8, 9, 7,   2, 6, 1,   3, 5, 4,

Thats' a black box test (or what I call end-to-end).  It's called
"black box" testing because you don't know how the solver works - all
you know is the input and output of the application.  I could alter
the inner workings of the transform and still expect all of my black
box tests to pass - which is the crucial distinction.

Unit testing (as you know) is about testing each component within the
program, following the principle that if each component works
correctly, the overall app is correct.

So in the Sudoku Solver a unit test would be a test on one of the
functions, such as:

<xsl:function name="fn:getRowNumber" as="xs:integer+" 
saxon:memo-function="yes">
   <xsl:param name="index" as="xs:integer" />
   <xsl:sequence select="(($index - 1) idiv 9) + 1" />
</xsl:function>

This function returns the row of a particular index, so index 9 should
be on row 1, index 10 should be on row 2 etc, and you can write unit
tests to check those assertions.

I can understand why you think this is a black box test because you
don't care how the function works, only its inputs and outputs, but
the "box" in "black box" and "white box" testing refers to the
application as a whole - the "box" is the transformation.

If I change the inner workings of the transform, I would need to
update my "white box" tests as they are tightly coupled to the way the
transform is written, but not my black box tests as they don't know
anything about the transform.


cheers
--
Andrew Welch
http://andrewjwelch.com
Kernow: http://kernowforsaxon.sf.net/



-- 
Regards,
Mukul Gandhi

--~------------------------------------------------------------------
XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--