Subscribe RSS FeedBy Ashiq Alibhai
Automated testing is a where developers write test-cases (via code, or some sort of action-recording device) which they can then run later at the click of a button. This code (test case) typically sets some things up, does some sort of action, then verifies the outcome against an expectation. Done en-mass, a proper selection of test-cases can help developers and quality-assurance test almost the entire application with little effort.
One question that often comes up with automated-testing is how to create independent tests—tests that don’t require more then one module. For example, if you have a login page, which pulls data from a database, how can you test if the login page is working without depending on the database working?
Enter "mock objects"–mock objects are used to mock expensive or hard-to-create resources. For example, you can create a "mock" database that always returns the same data, pretends it’s deadlocked, and so on—without the overhead of having a real database.
And this is one of the powers of mock objects—you can use them to eliminate dependences between different modules! If your application needs to connect to a database, grab XML from a remote server, and pull up a file from the file-system, then correlate the data—use mock-objects to eliminate the need of those modules to be working correctly. Simply return usable data, and test!
And of course, one of the drawbacks of mock objects is they’re not real—that cases may arise where the mock object is too fake, and although the test cases pass, the application fails on real data.
Mock objects are a tool, just like any other tool; and they can be used for good or for evil. Be wise, and make sure you understand what you’re mocking when you create your mock objects.
