Mocks, Stubs & Doubles

What

• Mocking is used for protocol testing - it tests how you'll use an API, and how you'll react when the API reacts accordingly.

• Ideally (in many cases at least), that API should be specified as an interface rather than a class - an interface defines a protocol, a class defines at least part of an implementation.

• Test doubles turn integration tests into unit/isolation tests

• https://8thlight.com/blog/uncle-bob/2014/05/14/TheLittleMocker.html

• https://martinfowler.com/articles/mocksArentStubs.html

• https://javacodehouse.com/blog/mockito-tutorial/

• https://www.codurance.com/publications/2019/04/08/introduction-to-test-doubles

• http://xunitpatterns.com/Mocks,%20Fakes,%20Stubs%20and%20Dummies.html

mockito

• https://stackoverflow.com/questions/22867680/how-does-mockito-mock-interfaces

• https://www.toptal.com/java/a-guide-to-everyday-mockito

mocks

• Cannot mock final class/methods using mockito 1.x, need latest version (use inline dependency)

How to control final classes

• If class is final but in your scope of change

  • Add an interface to the class to be controlled, and create a test class that implements that interface, then inject it into the system under test

• If class is final but not in your scope of change

  • Cannot add an interface

  • Can wrap the dependency (adapter), replace the call of the actual with the adapter in codebase and mock the adapter in the tests

How to verify non injected objects

• When a object is instantiated in the class under test, and want to verify that this object is used, we can use argumentcaptor

• Thus when we it is used (we check the captor is used in the mehtod we verify) then can grab use the object that was captured, use its method and assert on them

Links

• https://stackoverflow.com/questions/10598898/mockito-numberformat-mocking-nullpointer-in-when-method

stubs

• provide canned answers to calls made during the test, usually not responding at all to anything outside what's programmed in for the test

• Stubbing is the process of giving behavior to a function that otherwise has no behavior on its own—you specify to the function exactly what values to return (that is, you stub the return values).

• ie From mockito: when(...).thenReturn(...)

• typically done through mocking frameworks

• stubbing is appropriate when you need a function to return a specific value to get the system under test into a certain state

• each stubbed function should have a direct relationship with the test’s assertions.

• real implementations or fakes are still preferred because they don’t expose implementation details and they give you more guarantees about the correctness of the code compared to stubbing

Limitations

Dummy

• are passed around but never actually used. Usually they are just used to fill parameter lists.

Spy

• are stubs that also record some information based on how they were called. One form of this might be an email service that records how many messages it was sent.

Fakes

• A fake is a lightweight implementation of an API that behaves similar to the real implementation but isn’t suitable for production

• for example, an inmemory database, wiremock

• Using a fake is often the ideal technique when you need to use a test double, but a fake might not exist for an object you need to use in a test, and writing one can be challenging because you need to ensure that it has similar behavior to the real implementation, now and in the future

• Normally use an already written on

  • otherwise it is hard to create, as it must mimic the real implementation and must be maintained

Mocks

• are pre-programmed with expectations which form a specification of the calls they are expected to receive. They can throw an exception if they receive a call they don't expect and are checked during verification to ensure they got all the calls they were expecting

Interaction Testing

• is a way to validate how a function is called without actually calling the implementation of the function. A test should fail if afunction isn’t called the correct way; for example, if the function isn’t called at all, it’s called too many times, or it’s called with the wrong arguments.

• interaction testing is typically done through mocking frameworks

• Interaction testing is sometimes called mocking

• it is preferred to test code through state testing

• it can only validate that certain functions are called as expected. It requires you to make an assumption about the behavior of the code; for example, “If database.save(item) is called, we assume the item will be saved to the database."

• Leaks details to test

• when to use

  • You cannot perform state testing because you are unable to use a real implementation or a fake

  • Differences in the number or order of calls to a function would cause undesired behavior

  • PREFER TO PERFORM INTERACTION TESTING ONLY FOR STATE-CHANGING FUNCTIONS

  • you should perform interaction testing only for functions that are state-changing

With state testing

• you call the system under test and validate that either the correct value was returned or that some other state in the system under test was properly changed

• it actually validates this assumption (such as by saving an item to a database and then querying the database to validate that the item exists)

• if cannot state, use interaction testing, but also use integration testing

London/mockist school

chicago/classic school

Mocking frameworks

• A mocking framework is a software library that makes it easier to create test doubles within tests;

  • it allows you to replace an object with a mock, which is a test double whose behavior is specified inline in a test.

• The use of mocking frameworks reduces boilerplate because you don’t need to define a new class each time you need a test double.

why

• Essential for testing and not want to call anything which can have consequences (ie state change (internally or externally), production calls, charges for services)

• If you want to verify the behavior of the system under test (SUT), using mockito can be more effective as it allows you to verify interactions between the SUT and its collaborators.

Problems with mocking

• When you mock something you’re removing all confidence in the integration between what you’re testing and what’s being mocked.

  • You will need to do separate tests for integration part, to see that it actually works

• mocking is somewhat overused - often you're not really interested in the exact interaction, you really want a stub... but mocking framework can be used to create stubs, and you fall into the trap of creating brittle tests by mocking instead of stubbing. It's a hard balance to get right though.

• When using verify (to check a dependency has been called) this ties the test to the implementation/structure of the code, rather than the behaviour

  • better to have stub injected, and assert on the stub

  • dependencies are part of the constructor and thus public

• Can lead to mocking everything except the SUT

  • This can make test brittle

  • SUT is not necessarily a class, but can be a bunch of objects to test the behaviour

  • Over-reliance on mocks can lead to tests that are not representative of the real-world behavior of the system, resulting in tests that are less effective and less reliable.

• SUT with lots of dependencies and interactions, and use of mocks can make tests more complex and unclear with lots of extra code

• Leaks implementation details into your test

  • Ideally, a good test should need to change only if user-facing behavior of an API changes; it should remain unaffected by changes to the API’s implementation

• Use of mocking frameworks can lead to false sense of security

  • MAke tests hard to maintain

  • makes refactoring harder, as tests will break

  • bug finding hard

• test doubles, does not have exact sameness as the real implementation, so always some form of security that it is give correct evaluations

• https://engineering.talkdesk.com/double-trouble-why-we-decided-against-mocking-498c915bbe1c

• https://youtu.be/7AGQ9dhWCX0 Test Doubles Are A Scam – Matt Diephouse

• Mocking can add additional processing time during the build process, slowing down the overall build time.

alternative - use real implementations

• makes refactoring easier

• known as classical testing

• tests are more realistic, more confidence in the system

• Using real implementations can cause your test to fail if there is a bug in the real implementation.

  • A real implementation is preferred if it is fast, deterministic, and has simple dependencies. For example, a real implementation should be used for a value object

  • for more complex code, using a real implementation often isn’t feasible

    • ie database or network calls, edge of app. these can be mocked

    • ie for nondeterministic code such as external servers, time, randommness

• Can be slow

• Need to construct the object graph for the SUT, can be complex

  • Should use the same mechanism as test, and adjust (ie factories) to replace mocked dependencies

alternative - use fake implementations

• Instead of a real implementation, use an inmemory version

• This a fake or stub

• If there is a logic which mimics the actual impl in the fake, it needs to be tested to ensure it matches the real impl and be used with accuracy in the tests

Links

• https://medium.com/javascript-scene/mocking-is-a-code-smell-944a70c90a6a

• https://chemaclass.medium.com/to-mock-or-not-to-mock-af995072b22e

Mocking third party

• This should not be done, should avoid mocking third party code

• https://youtu.be/v6hP2MXoVrI Don't Mock 3rd Party Code