You may have heard many times that a test is a black box test. This simply means that the test does not know anything about how the system under test (SUT) is implemented. The test relies only on the interface of the SUT that is exported for the outside world. A white box test, on the other end of the scale, tests the internal working of the SUT and very much relies on the implementation:

Both the approaches have advantages and disadvantages. We should use one, or the mixture of the two approaches, a way that fits the purpose of the actual testing needs the most. A black box test not relying on the implementation does not need to change if the implementation changes. If the interface of the tested system changes, then the test should also be changed. A white box test may need changes if the implementation changes, even if the interface remains the same. The advantage of the white box test is that, many times, it is easier to create such a test and the testing can be more effective.

To get the best of both worlds, systems are designed to be testable. Be careful, though. It means many times that the functionality internal to the tested system is propagated to the interface. That way, the test will use only the interface and, thus, can be declared to be a black box, but it does not help. If something changes in the internal working of the tested system, the test has to follow it. The only difference is that you may call it a black box test if the interface also changes. That does not save any work. Rather, it increases it: we have to check all the modules that rely on the interface if they also need any change.

I do not say that we should not pay attention to creating testable systems. Many times making a system testable results in cleaner and simpler code. If the code, however, gets messier and much longer because we want to make it testable, then we are probably not going in the right way.