Black-box versus white-box testing for Go packages – an example

Black- and white-box testing are two different approaches to authoring unit tests. Each approach has its own set of merits and goals. Consequently, we shouldn't treat them as competing approaches but rather as one complementing the other. So, what is the major difference between these two types of tests?

Black-box testing works under the assumption that the underlying implementation details of the package that we test, also known as the subject under test (SUT), are totally opaque (hence the name black-box) to us, the tester. As a result, we can only test the public interface or behavior of a particular package and make sure it adheres to its advertised contract.

On the other hand, white-box testing assumes that we have prior knowledge of the implementation details of a particular package. This allows the tester to either craft each test so that it exercises a particular code path within the package or to directly test the package's internal implementation.

To understand the difference between these two approaches, let's take a look at a short example. The Chapter04/retail package implements a facade called PriceCalculator.

A facade is a software design pattern that abstracts the complexity of one or more software components behind a simple interface.
In the context of microservice-based design, the facade pattern allows us to transparently compose or aggregate data across multiple, specialized microservices while providing a simple API for the facade clients to access it.

In this particular scenario, the facade receives a UUID representing an item and a date representing the period we are interested in as input. Then, it communicates with two backend microservices to retrieve information about the item's price and the VAT rate that was applied on that particular date. Finally, it returns the VAT-inclusive price for the item to the facade's client.