- Errors, Defects, Failures
- White Box and Black Box Testing
- Classifying Tests
- The Agile Testing Quadrants
- Some Other Types of Testing
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
White Box and Black Box Testing
Testing takes on fundamentally different forms depending on whether or not we have access to the tested artifact’s internals—most notably its source code. White box testing refers to testing where we do have access to the source code and are able to inspect it, either for verification or inspiration for new tests. Black box testing is the opposite. We only have access to the tested artifact’s external interface, whatever that might be. When doing black box testing, there’s no way to inspect the internal state. Instead, the result of the tests is observed in the artifact’s output or by some other indirect means.
Because of how many companies organize their testing activities, testers tend to work from the black box angle, which means that they have to resort to techniques that don’t assume they know everything about the system they’re testing. Not only has this constraint given rise to various testing methods and techniques, but a black box approach imposes an emotional distance from the target of the test.
Black Box Development
This is a good place to halt the terminology tour and reflect on practices. Even when developers can inspect and access everything in the codebase, they should keep the black box approach in mind. Not only does it reduce coupling between test and production code, viewing the component or system as a black box helps when defining its contract and behavior. I strongly suggest that the following questions be raised for each method, class, component, or other artifact:
What is its interface to the outside world?
What inputs does it take? (Have all allowed values been specified?)
How does it communicate success or failure?
How does it react to bad input? (Does it recover or crash?)
Does it surprise by doing something unexpected or unusual?
Thinking in terms of contracts and behavior is both a fundamental and very usable design technique, and it leads to software that can readily be tested. Programming by contract and test-driven development, two techniques that will be introduced later in the book, both favor this kind of outside-in perspective.