Black-Box and White-Box Testing

Black-box and white-box testing

Generally speaking, tests against an existing system come in two flavors: black-box and white-box testing. The phrases far predate software testing and apply to any test process.

• A black-box test is so-called because it ignores the application’s internal structure and tests only top-level input into the system and returned output.

• Conversely, a white-box test uses knowledge about system internals to explicitly test specific paths through the code.

Black-box testing

A black-box test is a test that depends only on the external interface of code without relying on the internals. We can think of the internals as an opaque black box that we can’t see inside. We already did black-box testing of Rails applications back in the capter “Integration Testing with Capybara and Cucumber.” A black-box test of a Rails application works only at the level of user input and system output, typically HTML. That sounds a lot like a Cucumber or Capybara integration test. Since integration testing works outside the normal Rails code, it’s ideal for interaction with legacy code.

Integration testing

The integration tests interact with the system as a user would. Since there is no interaction with the code’s internal structure, it’s possible to write integration tests no matter how gunky the code is.

Integration testing and bug fixing

Integration testing can be useful in a bug situation because bugs are often specified in terms of the users’ actions and responses. These actions and responses are often reasonably straightforward to translate to Cucumber or Capybara, and it’s easy to recognize if we’ve changed the behavior. In addition, it’s not unheard of for a codebase with few tests to lack written requirements; the acceptance tests act as baseline requirements as we move forward.