Preparing myself for ISTQB, I found a bit odd many things in their textbooks. E.g. they call black box testing as functional testing when you are not concerned with structured but only observe the ouput based on inputs. But later they say that functional testing is done at levels..well, how can I do unit testing without the knowledge how it works if I can just see it (and must see it). It is white box but then it is in the conflict..


When you are doing unit testing, you do not care about the actual implementation of the solution, only that it gives the expected results. The difference being the level of unit that you are testing. If you are testing a class, you are not making sure that internal methods are called but that the correct response is returned. How the unit gets the response is not what you are testing for.

The different levels of testing cover the interaction and logic of the pieces of your implementation but are agnostic of what they actually are.

UPDATE Generally, developers do fine grain unit testing. However, even a tester can do lower level unit testing. Focusing on specific pieces of an operation, for example sending data to the server themselves rather than through the web interface (removing the web interface from the unit). Or for testing the web interface, spoofing the response provided so that you are able to test its behavior in isolation.

Knowing the implementation would allow you to determine the lower level 'units', however the tests themselves do not know anything about the actual details of the solution.

  • Still I cannot see why unit testing is given as typical white box and then you can read that it should be black box..I guess I am confusing approaches and techniques or something like that. – John V Apr 8 '13 at 19:40
  • You need to be able to see what is going on to determine lower level units so hence white box. But when doing the test it would be considered black box as you are not looking at what is going on inside the system. – Schleis Apr 8 '13 at 20:50

You can do black box or white box testing at any level of abstraction. Consider the following function:

double getDistance(double side1, double side2) {
    return pythagorean(side1, side2);

A black box test would check that you got the right answer. A white box test would also check that pythagorean() got called, rather than lawOfSines(), for example.

The next level of abstraction up might have a function like:

boolean inRange(double x, double y) {
    return getDistance(x, y) <= getMaximumRange();

A black box test at this layer would check certain values precalculated to be in or out of range. A white box test would also check that getDistance() and getMaximumRange() were called with the correct values during the calculation. That makes getDistance() a white box detail at this layer, even though it was a black box detail at a lower layer.

The vast majority of the time, unit tests should not care about the implementation at all. i.e. you should be doing black box tests. Often white box unit tests are unavoidable, but they should be minimized, so the coupling of your tests to your implementation is minimized.

  • Then why unit tests are always presented as typical white-box testing example? Because you can see inside? But then it would be white box approach and yet doing black box tests? I do nto get it .. Or I can choose? WHen using white, I generate cases from code (control flow) while in black box, I just test what it should do. – John V Apr 8 '13 at 19:27
  • Because if you don't specify a level of abstraction when talking about black vs. white box, the application level is assumed. Unit tests require knowledge of the "units" of an application, therefore are white box tests at the application level. – Karl Bielefeldt Apr 8 '13 at 19:46
  • I cannot agree that unit test should not care about the implementation. This is the core of coverage techniques. How do you want to achieve 100% condition coverage without looking in the code? – John V Apr 9 '13 at 6:20

Black box testing means that you don't need to know what is inside the box in order to build your test. It doesn't specify how big or how small the box is.

Unit testing means that you test units of code one by one. This is by contrast with integration testing in which you test several units interacting together. It doesn't specify how small or how big the units are.

Functional testing defines testing criteria based on the function of the code under test, by contrast with structural testing in which testing criteria are based on the code structure. Functional testing is a black box testing technique.

Code coverage is a group of testing criteria that belongs to the glass box testing category (not white box testing as white is as opaque as black).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.