I only believe that theres only one kind of testing. Black box testing. And that is broken into two types. Integration and unit.
Tests that validate the interface of the big black box and assert that it does the right thing (integration tests). I.e assert the behavior customers depend on.
That black box is made up of many smaller black boxes that talk to each other. So you test the boundaries of each of those smaller black boxes. (Unit tests)
The ROI for testing the big black box is much higher. But when something fails it’s hard to know what exactly caused it and how to fix it. If you have a decent number of tests for the smaller black boxes then you know what box needs to be fixed.
But all good tests are black box tests. I.e they don’t test the internals but the interface of using that box.
A well designed system is made up of small boxes that do one thing very well and work with other boxes. Once you’ve tested them you can forget about them and work on higher abstractions. They will continue doing what they promised.
Tests that validate the interface of the big black box and assert that it does the right thing (integration tests). I.e assert the behavior customers depend on.
That black box is made up of many smaller black boxes that talk to each other. So you test the boundaries of each of those smaller black boxes. (Unit tests)
The ROI for testing the big black box is much higher. But when something fails it’s hard to know what exactly caused it and how to fix it. If you have a decent number of tests for the smaller black boxes then you know what box needs to be fixed.
But all good tests are black box tests. I.e they don’t test the internals but the interface of using that box.
A well designed system is made up of small boxes that do one thing very well and work with other boxes. Once you’ve tested them you can forget about them and work on higher abstractions. They will continue doing what they promised.