View mode: basic / threaded / horizontal-split · Log in · Help
March 04, 2005
black box unit testing
On Fri, 04 Mar 2005 10:33:21 +0000, Stewart Gordon wrote:

> Knud Sørensen wrote:
> <snip>
>>> (c) If we're going to enforce black-box unit testing, then the 
>>> syntactic salt for tests ought to be in the code, rather than on 
>>> the command line.
>> 
>> No, consider a team where one developer cheat and compile with 
>> --allow-white-box, then the other developers will notice as soon they 
>> compile the code.
> 
> If by your conception using --allow-white-box is cheating, why allow it 
> at all?

If the team have committed to black-box unit testing then white box
unit testing is cheating.

But it takes time to learn how to write good testable code,
so a newbie might like to use --allow-white-box.


>> If you hide the white-box stuff in the code they might never know and
>> we would not be enforcing black-box testing would we ??
> <snip>
> 
> What have you against white-box tests?  

I would rather tell you why I like black box unit testing.

The short answer is that it encourage you to write good code.

The long is 
1) Decouples the unit test from the class implementation.
So, You don't have to change the unit test when your 
change the class implementation only when you change the interface.

and when used with 100% unit test coverage.

2) Eliminate dead code from the class.
Dead code can't be test with black box testing
so it shows up in the coverage analyses.

3) Find code with hidden dependencies.
This is also hard to black box test 
and will show up in the coverage analyses.
Here we need to use dependency injection.

etc.. I am sure that the is many more.


>  I.e. if someone _wants_ to put 
> in some code to test the internal workings, why give the outside user 
> the trouble of knowing that they have to compile with ? 

When an developer wants to use white box unit testing for internal
working it is almost always a sign that there is some code that 
should be refactored to another class and/or tested with mock obejcts.

Often the developer have never heard of mock objects and/or dependency
injection.

That it is troublesome to tell the user to compile with --allow-white-box
will only encourage the developer to learn about better ways to test the
code.

>   My point is that there should be a notation to separate the white-box
> tests (to check that it works from the developer's point of view) from
> the black-box tests (to check that it works from the user's point of
> view).

Let make it clear what we mean by developer and user.

We have the application (app) level and the class level.
Let call them app user, app developer and class user and class developer.

Let say that the app developer is also the class user but not the class
developer. 

An app developer would call the functional test
for black box testing and unit testing for write box testing.

An class developer would call 'black box' unit testing for black box
testing and test where you compile test code in, use debugger or valgrind
for white box testing.
 
When I write a application I split it in 5 layers.
Interface layer,
application layer 
domain layer 
technical layer
platform layer.

Then when I write functional test I only "talk to" the interface layer.
If I wrote a functional test which depended on a matrix library from the
technical layer, then I would have to rewrite the test if I decided 
to use another matrix library and I would be testing the implementation 
not the functionality.

In the same way with black and write unit test.
Blacks test the functionality of the class
while white test the implementation directly.

So, allowing white unit tests make the code hard to refactor and maintain.
March 04, 2005
Re: black box unit testing
Knud Sørensen wrote:
<snip>
> When an developer wants to use white box unit testing for internal
> working it is almost always a sign that there is some code that 
> should be refactored to another class and/or tested with mock obejcts.

To me, it's a sign that the user wants to test some aspects of the 
internal workings when they might expose bugs to the effect that some 
cases (missed by the black-box tests) might not work.  Or maintain 
checks that the workings are working before writing more public functions.

<snip>
> In the same way with black and write unit test.
> Blacks test the functionality of the class
> while white test the implementation directly.
> 
> So, allowing white unit tests make the code hard to refactor and maintain.   

If they want to refactor, it goes without saying that this would include 
refactoring the white-box unit tests as appropriate.

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on 
the 'group where everyone may benefit.
Next ›   Last »
1 2
Top | Discussion index | About this forum | D home