{"id":5003268,"date":"2015-12-16T23:15:18","date_gmt":"2015-12-17T07:15:18","guid":{"rendered":"https:\/\/aadev22.local\/?post_type=aa_glossary&p=5003268"},"modified":"2023-03-08T15:41:28","modified_gmt":"2023-03-08T23:41:28","slug":"mock-objects","status":"publish","type":"aa_glossary","link":"https:\/\/agilealliance.org\/glossary\/mock-objects\/","title":{"rendered":"Mock Objects"},"content":{"rendered":"

A technique commonly used in the context of crafting automated unit tests<\/a>. It consists of instantiating a test-specific version of a software component (typically a class), which instead of the normal behaviors provides pre-computed results, and often also checks that it\u2019s invoked as expected by the objects being tested.<\/p>\n

For instance, the \u201cmock\u201d version of a database component will a) provide \u201ccanned\u201d answers to database queries, instead of connecting to a real live database, and b) verify that the database is being accessed in the manner expected and stipulated in the test.<\/p>\n

Also Known As<\/h2>\n

There are many terms for components that mimic actual code for the purposes of testing: mocks, stubs, fakes, spies, and dummies to name the more common.<\/p>\n

These terms are not strict synonyms, various authors make relatively subtle distinctions between these categories, based on whether the components have behavior, record interactions with other components, etc.<\/p>\n

The generic term \u201ctest double<\/a>\u201d has been proposed to refer to any such component (an allusion to \u201cstunt double\u201d).<\/p>\n

Expected Benefits<\/h2>\n

Mock objects afford \u201cdecoupling\u201d software components for the purposes of testing. For instance, code that is relied upon should not be \u201ccoupled\u201d to the implementation details of that database: its correct function relies on the logical organization of the data being queried, rather than on concrete aspects such as storing data on disk or establishing connections over network protocols. Mock objects lead to tests that only exercise the behavior of the software components under test, and do not depend on the behavior of other, unrelated components.<\/p>\n

Common Pitfalls<\/h2>\n

The technique is slightly controversial, having both adepts and detractors; the latter argue that overuse of mock objects leads to a heavier test maintenance burden, and detracts from the tests\u2019 role as documentation, and these drawbacks are not always adequately compensated by the benefits of mock objects.<\/p>\n

Origins<\/h2>\n