Jest clear mocks code#

Jest clear mocks code#

‍ The reason I prefer the other solution is that this option doesn't actually fix the root cause of our problem - we are still sharing context between tests through the mock function - we only address the symptom by explicitly clearing the part of the shared context that we noticed was affecting our tests.Testing code with Ajax, networking, timeouts, databases, or other dependencies can be difficult. For the purposes of tracking calls, it would be sufficient to add a mockClear for our function before each test. This requires a little more attention to detail and understanding the different ways to reset mock functions. Reset the mock calls in beforeEach or before specific tests. The disadvantage of this approach is in cases where creating the mock implementation relies on something that is time / resource heavy to create, so running the setup before each test would cause performance issues. ‍ This is generally my preferred method, as it requires little to no thinking and it solves the problem at the root - we will not share context between tests because the context is created separately for each test. ‍ As a rule of thumb for not accidentally sharing context between tests - try to avoid const definitions outside test setup unless they are for immutable values like strings or numbers. As we did in the original example, we can create all test context in beforeEach hooks rather than globally / directly under describe. There are two main ways to resolve such issues: 1. The test that expects mockPredicate to have been called would pass because the previous test scenario already called the mock function with 10. ‍ ‍ Jest types already provides the useful MockedFunction type for this purpose, in our repository we added a couple of additional helpers: ‍ Luckily for us, we can use typescript to create this coupling of an interface and a mock function - we just have to be a little more explicit when we write the mock function and specify the type of the function it is supposed to mock. This mistake is not caught by typescript because jest.Mock and jest.fn() are typed as a function from any to any, so the typescript compiler is willing to accept our mock as the predicate, even though its implementation returns the wrong type. This is because our mock predicate was not updated to return a promise as the interface requires, it still returns false. In our tests, however, this bug will not be caught even though in theory we have this case covered by the when the predicate is false test case. ‍ The code itself is still valid in terms of typescript but it is no longer correct - predicate now returns a promise, and a promise is always considered true, which means that predicateOrZero will not return 0 even if the predicate evaluates to false.

For example, let's consider testing the following function: ‍ Having mock implementations decoupled from the interfaces they supposedly mimic makes it very easy to miss mocks during a refactor and could lead to a situation where some tests are not failing even when the code has a bug in the scenario under test. The problem begins when the code undergoes refactoring and some interfaces change over time. This is usually not a major problem when the test is first written, because it is fairly easy to create a mock of a specific function / interface. There is nothing preventing the mock function from returning the wrong type of answer. This worked great for a while, but the problem with using jest.fn() is that it creates a mock function that is completely decoupled from interface of the function being mocked. In our early tests we would create mock functions in the most straight forward way with jest.fn(). Jest has a really nice framework for creating mock functions for unit tests and we use that framework quite extensively.