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

Subject: Re: [xsl] ANN: 'Testing XSLT' training course PDF available
From: "Mukul Gandhi" <gandhi.mukul@xxxxxxxxx>
Date: Tue, 18 Dec 2007 19:01:58 +0530
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.j.welch@xxxxxxxxx> wrote:
> On 18/12/2007, Florent Georges <lists@xxxxxxxxxxxx> 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

Current Thread