Topic: Separation of Interface from Implementation

Message

   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 finds herself writing code that interacts with
the database.
This is a mistake, because a unit test should never go outside of its
own class boundary. As a result, the software developer abstracts an
interface around the database connection, and then implements that
interface with their own Mock Object. This results in loosely coupled
code, thus minimizing dependencies in the system.

Author	Message
papri Newbie Joined: 05Apr2007 Online Status: Offline Posts: 1	Topic: Separation of Interface from Implementation Posted: 05Apr2007 at 2:43am
	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 finds herself writing code that interacts with the database. This is a mistake, because a unit test should never go outside of its own class boundary. As a result, the software developer abstracts an interface around the database connection, and then implements that interface with their own Mock Object. This results in loosely coupled code, thus minimizing dependencies in the system. Post Resume: Click here to Upload your Resume & Apply for Jobs

	IP Logged


One Stop Testing Forum : Types Of Software Testing @ OneStopTesting : Unit Testing @ OneStopTesting