In the last post I briefly mentioned the concept of black box testing. A black box overall in computer science terms refers to a system or a component that has a set of known inputs and a set of known outputs. Outputs which are generated by some kind of transformation. The contents of that box, or more specifically the internal operational details, are hidden away from the user.

A car can be thought of as a black box since the driver only needs to know that putting his feet on the pedal will cause the car to move forward. How that is done, is a detail which the user is not concerned with.

In software this concept becomes useful when designing the system with its different parts. The stated rule is that whenever a function or capability is seen as necessary during the design stage, it should be defined as a black box. It should be used within the system without having the concern of how that black box operates internally. Design does become more difficult when we concern ourselves with finer details instead of focusing on the bigger picture of the relationship between various parts. This is the where the idea of black boxes becomes very useful.

It’s interesting to think about how the properties of a box change at different stages. When writing tests for example, we are inspecting the internal behaviour of some class/module and this can be thought of as a white box. However the lower level components of that box, like functions, are black in the sense that we provide some input and assert on the expected output. When we finish, the user of that class/module (possibly another module), should see it as a black box and thus we should see that relationship as such too.

Knowing when to make the mental switch between the various stages can aid in our quest for a better design.