Black or white – what is a difference?
Black box testing is an approach, where test checks the correctness of the interface of unit, module, device, system, etc. without knowledge about “what is inside?”.
White box testing is an approach, where test uses the interface of unit, module, device, system, etc. and checks behaviour of internal implementation.
Another definition number 1235713 in the web, great job!
You can easly find similar definitions in the internet, but often after that definitions you can find some incorrect examples like “white box testing is performed by software engineers and black box testing is performed by testers”. The main problem that can be noticed in projects in IT is assigning black or white to the level of testing (unit tests, module tests, system tests, etc.) instead of assigning to purpose of the test.
OK master, give us proper examples!
The tendency is using the white box approach instead of the black box. Usually this is a result of incorrect architecture, laziness, lack of experienced people or even project decisions put in some guidelines. Let’s then exmplain cases, when using the white box testing approach is reasonable.
The simple and not obvious at the first moment example is… Coverage Tests! Yeah, how we can check if we cover X% of the code without knowledge about the code?
More examples? Loop Testing! Memory leak testing! Again, we need to know the internal implementation to get the result of that tests. Still not enought? Please look at the table:
| Test type | Proper approach |
|---|---|
| Performance Test | Black box |
| User Interface Test | Black box |
| System Test | Black box |
| Module Test | Black box |
| Unit Test | Black box |
| Coverage Test | White box |
| Memory leak Test | White box |
| Loop Test | White box |
| Penetration Test | White box |
You will not find tests like Smoke Test, Regression Tests, Acceptance Testing, Stress Testing, because they usually are set of other types of tests, which you can find in the table.
What the … Unit Test is Black? Maybe to many copy-paste in “approach” column?
No. Unit Test is Black Box Testing. Of course you can easy find in the web that Unit Test is White Box, but this is the result of interpretation from a different perspective. If we have a project, thousands lines of code and we would like to test single class we need to know project’s code. Project’s code, not class’s code. In this perspective, we can say that we use White Box approach. However, if we create and deliver a class to the project, our product is that class. We need to guarantee that the class’s INTERFACE is working as expected, not that class’s members have given state or some private methods are called. In this perspective Unit Test uses the Black Box approach.
If you still prefer White Box approach for Unit Testing, answer the question “why not Black Box”? Does testing your unit really need to know about the internal implementation? Or maybe just an architecture of your code does not allow it? Refactor it until it’s too late. For instance Coverage Test really needs to know the internal implementation. When you use basic best programming practices like SOLID trust me, Unit Test don’t need to use hacks like #define private public or static variables.
I will code Unit Tests by using White Box approach and what you will do to me, huh?
Me nothing. Your code will make you a big surprise in the next months, when new features, change requests or new requirements will come. Then, instead of using Unit Tests as a part of regression tests, which should tell you if old functionalities still work when you add new ones, you need to implement: new functionalities, which probably change some private methods, new “Unit Tests” for new functionalities and… yes, new “Unit Tests” for old functionalities, because the internal implementation has been changed. But no problem, we perfectly remember all cases of old code usages. Moreover, in case of small hole in our memory we have clear and full documentation for our code 🙂
