White box testing

White box testing is a software testing methodology that uses source code as the basis for designing tests and test cases. White box testing takes an inward look at the framework and components of a software application to check the internal structure and design of the software. White box testing is also called transparent, clear and glass box testing for this reason. This test type can also be applied to unit, system and integration testing.

White box testing usually involves tracing possible execution paths through the code and working out what input values would force the execution of those paths. The tester, who is usually the developer that wrote the code, will verify the code according to its design- which is why familiarity with the code is important for the one initiating the test. Code is tested by running input values through the code to determine if the output is what should be expected. Testers can work out the smallest number of paths necessary to test, or "cover," all the code. Static analysis tools will aid in the same job, more quickly and more reliably.

White box testing, on its own, cannot identify problems caused by mismatches between the actual requirements or specification and the code as implemented, but it can help identify some types of design weaknesses in the code. Examples include control flow problems (e.g. closed or infinite loops or unreachable code) and data flow problems. Static code analysis (by a tool) may also find these sorts of problems but does not help the tester/developer understand the code to the same degree that personally designing white-box test cases does. Tools to help in white box testing include Veracode's white box testing tools, Googletest, Junit and RCUNIT.

Advantages & disadvantages

Advantages to white box testing include:

• Thorough testing.
• Supports automated testing.
• Tests and test scripts can be re-used.
• Testing is supported at earlier development stages.
• Optimizes code by removing any unnecessary code.
• Aids in finding errors or weaknesses in the code.

Disadvantages include:

• Test cases are often unrepresentative of how the component will be used.
• White box testing is often time consuming, complex and expensive.
• Testers with internal knowledge of the software are needed.
• If the software is implemented on frequently, then time and cost required

White box testing vs black box testing

Black box testing is the opposing form of testing compared to white box testing. The implication is that you cannot see the inner workings of a black-painted box; and in fact, you do not need to. Black box testing will design test cases to cover all requirements specified for the component, then use a code coverage monitor to record how much of the code is executed when the test cases are run. Unlike white box testing, black box tests do not need developers who worked on the code. All the testers need to be familiar with are the software's functions. Other differences between black and white box testing are that black box testing is based on requirement specifications rather than design and structure specifications. Additionally, black box testing can be applied to system and acceptance tests rather than unit, system and integration tests.

The term "gray box testing" is used for internal software structures that are not actually source code - for example, class hierarchies or module call trees.