Black-box Testing

Introduction

In this section, we will introduce a high-level concept called black-box testing. Black-box testing involves testing (including unit testing) the application code with no prior knowledge of its internal implementation. In black-box testing, you provide inputs and observe outputs without understanding the underlying implementation. This makes it possible to identify how the system responds to expected or unexpected user actions.

The principles of black-box testing apply to testing in general. It is applicable to unit, integration, and end-to-end testing.

More about black-box testing

The level of unit testing transparency can either be black-box or white-box. One of the main differences is how much the tester knows. With white box testing, the tester needs some knowledge of the internal workings of the code to write tests. Another difference is how the test cases are generated.

With black-box testing, emphasis is placed on how the application code should interact with the outside without knowing the implementation details. In other words, the emphasis is on coming up with all use cases on how a public interface should behave. In this sense, black-box tests are advantageous because they are independent of the internal implementation details.

Contrasting black-box and white-box testing

White-box testing is a technique that evaluates the code and the internal structure of a program to assist in writing tests. In contrast, black-box testing focuses on testing more of how the unit of application code should interact with the outside without necessarily understanding or seeing the internals of the application code. Gray-box testing is a combination of white-box and black-box testing. The differences between black-box, white-box, and gray-box testing are highlighted below:

Black-box testing	Gray-box testing	White-box testing
It analyses fundamental aspects only, i.e., no knowledge of internal working.	It has partial knowledge of internal working.	It has full knowledge of internal testing.
It is the least exhaustive and least time-consuming.	It is somewhere between black-box and white-box testing.	It is potentially the most exhaustive and most time-consuming.
Granularity is low.	Granularity is medium.	Granularity is high.
It is performed by the end-user and tester.	It is performed by the end-user and tester.	It is performed by the developer and tester.
This testing is based on external perceptions, and the internal behavior of the program is ignored.	Test design is based on high-level database diagrams, data flow diagrams, knowledge of the details of the algorithms used, and software architecture.	Internal structure is fully known.
This testing is driven by inputs not dependent on internal implementation details.	It allows data domains and internal boundaries (edge cases) to be tested.	There is better testing of data domains and internal boundaries.
It is not suited for algorithm testing.	It is not suited for algorithm testing.	It is suited for algorithm testing.

Advantages of black-box testing

Black-box testing is a best practice form of testing. This is because we are generally interested in how a program behaves through its interface. However, there are instances where white-box testing is preferred. For example, you might need to know the internals of algorithms/methods to know what requires testing and how to test the various use cases.

Transition from white-box testing to black-box testing

There are two mechanisms to shift from white-box testing to a black-box testing approach:

• Mechanism 1: Shift from testing private helper methods to testing public interface methods.

  Remember: If private methods and implementations are very complicated or involve algorithms, it may not always be enough to only test the public methods. In this instance, it is acceptable to test the implementation details.

• Mechanism 2: Shift from the test after development approach to the test-driven development approach.

  Remember: This may not always be the best approach if the software design and interface is subject to change during development. In this instance, it is acceptable to follow a test after development approach.

Conclusion

The differences between white-box and black-box testing are based on whether the internal implementation details are inspected to develop test cases. Since we are mostly concerned with interface over implementation, it is important to change your unit testing to the black-box approach. There are two mechanisms to shift from white-box to black-box testing. The first mechanism is to only test the public interface methods. The second mechanism is to adopt the test-driven development approach over the test after development approach.