- Tags:: [[Software Testing]] [[Software Development]] - Related:: [[Test doubles]] [[Stubs]] [[Service virtualization]] <!--ID: 1631100131238--> - Date Created: [[2020-09-12]] - A mock is a type of test double. It temporarily replaces a component to enable testing on other integrated components, but mocks are more involved than hardcoded test doubles like stubs: they can be configured to respond differently to different types of requests, which makes them more suitable to testing than development. - "`Mock: a programmable interface observer, that verifies outputs against expectations defined by the test. It is frequently created using a third party library, for example in Java that is Mockito, JMock or WireMock. It is most useful when you have a large suite of tests and a stub will not be sufficient because each test needs a different data set up and maintaining them in a stub would be costly. The mock lets us keep the data set-up in the test. `" - "`Now two examples situations where a mock is likely a good choice: `" - "`If you are a back end developer working on a fairly large application and you need to decouple from any HTTP API dependencies, use a remote mocking framework such as WireMock or mountebank and prime the mocks in the acceptance tests.`" - "`If you are a back end developer working with a code base that has thousands of class unit tests then Mockito could allow you to mock the dependency classes in any tests.`" - In [[Tabcorp]], we used [[Mountebank]] to mock up the responses from different systems like CAM (a payment system) and Bravo (betting server). Each bet request contained things like the account being used, the betting type, and the amount, and the responses needed to be tailored to each combination of those. Both the requests and the responses had to be converted to hexadecimal and then to binary, but using Mountebank meant that we didn't need to spin up real instances of those applications.