The black box test is the easiest test there is because it does not depend on implementation details of how what is being tested works. To apply the black box test just know how to interact with the public API of that, so if it is a method just know what arguments pass to it and what result it will give you. If it is a class, you can take the test only by understanding its general functioning, how it builds and manipulates its behavior and state.
He calls himself a black box because you don’t see what’s inside the box.
Black box testing is only one technique that can be applied to any kind of test what are you doing, be a unit test, integration or other.
The black box test test only if certain sets produce the expected result. It takes the specification obtained from the problem and applies its concepts to see if it happens as expected, no matter how it does internally.
This test can be applied by someone very connected in software development but who does not currently program since it does not require advanced specific knowledge of programming, it does not take care of the code.
It’s easy to apply but hard to do properly for the same reason it’s hard to develop software, have the right requirements and model something that meets these requirements is always harder than writing code that anyone can learn in days, modeling depends on a lot of experience and broad reasoning.
One of the criticisms I make of testing is that if you can fail so much in modeling, you’ll probably fail the tests. This is no reason not to test, but it is reason not to give as big credit to tests as silver bullet to get quality software.
In the ideal world there would be one person specifying, another writing the codes and a third creating the tests that ensure that everything is correct, but if this third does bureaucratically starting from the work of the first has little advantage. And it would be nice to have one that questions everyone’s work, so it’s easier to find mistakes, but it’s expensive. In practice this rarely happens and decreases its value.
The bad part of it is that it does not guarantee that everything that can be executed will be. It is not known what can go wrong for various reasons. And a good test is what tests what can go wrong and doesn’t test for what goes right. With the black box test you can try bad values, but you can’t force certain parts to run in a certain way because you don’t know what’s there.
White Box
He opposes the white box test that seeks to evaluate every detail of the code. Well roughly (this is technically wrong, just to make an analogy) we can say that the black box test is like object-oriented programming and the white box test is like imperative program. The first takes care of the general structure the second takes care of the implementation detail. The white box test takes care of the flow control and the specific decisions made, change of the internal state of the objects and local methods data. That is, it is the opposite of what the other answer cites as an example. The correct example there would be to test each wire, each gear in the motor, if each minimal element is behaving as it should.
Sure, there’s a plethora of things to talk about, but the would be a very broad response.