Hiding data is an important component of OOP. You need to give careful consideration to which components should be left public and which should be left private.
In general, data members are private, with the functions that allow you to examine and change them kept public.
If too much is left public, then tampering and misuse of implementation details can result.
If too much is left private, then inefficiencies and access problems can result.
If you properly gauge public and private portions of an object, then code is more easily debugged and maintained because errors and modifications are localized.
Client programs need only be aware of the type's public interface specification.
Objects encapsulate data and implementation and the user of an object can view the object as a black box that provides services.
Black Box versus White-Box Testing
Testing the functionality of the program without consideration of its internal structure is called black-box testing.
This is an important part of testing, because, the users of a program do not know its internal structure.
If a program works perfectly on all positive inputs and fails gracefully on all negative ones, then its function is fulfilled.
It is impossible to ensure absolutely that a program will work correctly on all inputs, just by supplying a finite number of test cases.
As the famous computer scientist Edsger Dijkstra pointed out, testing can only show the presence of bugs, not their absence.
To gain more confidence in the correctness of a program, it is useful to consider its internal structure.
Testing strategies that look inside a program are called white-box testing.
Performing unit tests of each procedure and function is a part of white-box testing.