Separation of Interface From Implementation
Because some classes may have references to other classes, testing a class can frequently spill over into testing another class. A common example of this is classes that depend on a database: in order to test the class, the tester often writes code that interacts with the database. This is a mistake, because a unit test should usually not go outside of its own class boundary, and especially should not cross such process/network boundaries because this can introduce unacceptable performance problems to the unit test-suite. Crossing such unit boundaries turns unit tests into integration tests, and when test cases fail, makes it less clear which component is causing the failure. See also Fakes, mocks and integration tests
Instead, the software developer should create an abstract interface around the database queries, and then implement that interface with their own mock object. By abstracting this necessary attachment from the code (temporarily reducing the net effective coupling), the independent unit can be more thoroughly tested than may have been previously achieved. This results in a higher quality unit that is also more maintainable.
Read more about this topic: Unit Testing
Famous quotes containing the words separation of and/or separation:
“There is nothing that I shudder at more than the idea of a separation of the Union. Should such an event ever happen, which I fervently pray God to avert, from that date I view our liberty gone.”
—Andrew Jackson (17671845)
“Just as children, step by step, must separate from their parents, we will have to separate from them. And we will probably suffer...from some degree of separation anxiety: because separation ends sweet symbiosis. Because separation reduces our power and control. Because separation makes us feel less needed, less important. And because separation exposes our children to danger.”
—Judith Viorst (20th century)