As a QA testing agency, we're experts in so-called 'black box testing'. That is, approaching a piece of software as a 'black box' where we assume no knowledge of the inner workings of the system.
Of course, in actuality we often know quite a bit about the system architecture and integrations which helps us to find defects. But the point is, we most commonly test an application from the black box perspective because it mimics the everyday user's experience.
However, this is only one piece of the overall software quality picture and we often recommend that development teams conduct much lower level tests of their own - integrated into their development process - as well as working with third party testers like ourselves. People often call this 'white box testing', or will use 'unit testing' interchangeably.
But, is there actually a difference between white box testing and unit testing?
What is white box testing?
Developers conduct white box testing during development. They use it to both check the outputs of the items being tested, and to check the internal variables that lead to that output. The focus can be on the specific code that was changed, or at a higher level of the entire module. In this way, they verify how the code is working and how it integrates with the overall infrastructure.
A note on grey box testing
Programmers can test their own code or may 'pair review' the code with a QA engineer in a process sometimes described as 'grey box testing'. This means that some knowledge of the source code being tested is held by the tester. Grey box testing may also refer to a team of developers and testers with varied knowledge of the source code, working together to perform tests at different levels.
What is unit testing?
Unit testing is (usually) also handled by the developers. It's a straight-forward method to test the smallest possible individual components - individual sections of coding logic and algorithms - of a system for successes and failures. It's an excellent way of uncovering issues within a specific feature that is being added or changed and catching bugs before being pushed into QA for complete testing.
Where are the similarities?
Both testing methods:
- Are commonly performed by developers during programming, rather than external parties.
- Focus at the level of the code, as opposed to QA engineers that are focused on the application functionality as accessed through the UI.
- Require coding skills and understanding of algorithms.
- Require knowledge of the specific source code being tested.
Where are the differences?
White box testing is considerably more expert-driven, time-consuming and complex, even if you've automated some parts of the process. Unit testing is simple and quick to implement because it looks at sections of the code, rather than the bigger picture. You can perform unit tests manually or, more often, automate them with a tool like Selenium. White box testing can be applied at the system, integration or unit level.
Does it matter?
By using the terms interchangeably, you may be missing out on the benefits brought by one of these testing methods - the things that set them apart from one another.
White box testing tells you more about the flow and interactions of the modules, and unit testing gives you granular information on each element. They often operate in conjunction, but there is a significant yet subtle difference in what you will uncover with each approach.
As in life, testing is like a box of chocolates: you never know what you're going to get.
See this article for more information on different testing types.
