Mocking and Stubbing in Frontend Tests Quiz

Delve into the core practices of mocking and stubbing within frontend testing. This quiz explores their roles, best use cases, and differences to boost your understanding of reliable and isolated test strategies in modern web development.

1. Purpose of Mocking

   In the context of frontend testing, what is the primary reason for mocking a module, such as an HTTP request utility, during a unit test?

   1. To isolate the component from external dependencies and control responses
   2. To ensure the test executes more animations smoothly
   3. To prevent the browser from crashing on large payloads
   4. To improve the visual rendering of UI elements

   Explanation: Mocking allows you to replace real modules or functions with controlled test doubles, enabling isolation from unpredictable external factors and consistent test results. Improving visual rendering (option B) and smoother animations (option C) are not related to the logic or flow control achieved by mocking. Preventing browser crashes on large payloads (option D) is a performance concern, not directly addressed through mocking.

2. Difference Between Mocks and Stubs

   When testing a form submission handler, what distinguishes a stub from a mock in terms of their expected usage and behavior?

   1. A stub improves performance, while a mock increases test coverage
   2. A stub creates real network requests, while a mock never interacts with APIs
   3. A stub only checks arguments, while a mock rewrites source code
   4. A stub provides predefined outputs, while a mock also records how it was used

   Explanation: Stubs focus on providing controlled outputs for certain functions, enabling predictable test results; mocks extend this by also tracking how those functions are called, such as the number of invocations or the arguments. Option B confuses functionality—stubs typically do not check arguments, and mocks do not rewrite source code. Option C is incorrect, as both stubs and mocks are meant to avoid real network interactions. Option D makes vague claims that do not capture their technical differences.

3. Selecting Between Mocks and Stubs

   Given a user profile component that displays data from a backend, which approach is preferable if you want your test to focus solely on verifying the display logic with controlled data?

   1. Allowing actual backend calls for realistic scenarios
   2. Injecting typos in backend endpoint URLs
   3. Using stubs to supply fixed backend responses
   4. Creating mocks that randomly change values

   Explanation: Stubs are well-suited for providing consistent, predetermined data—ideal for focusing tests on how that data is displayed, rather than how it is fetched or generated. Randomly changing values through mocks (option B) would reduce test predictability. Allowing real backend calls (option C) makes tests less reliable and harder to isolate. Option D, injecting typos in endpoints, does not represent a proper testing approach and could cause false negatives.

4. Risks of Not Mocking or Stubbing

   What is a common risk when frontend tests do not use mocks or stubs for API calls, relying directly on the backend service?

   1. Form validation rules will be disabled
   2. Tests may become flaky due to network errors or backend state changes
   3. Test scripts will skip execution automatically
   4. UI animations might slow down considerably

   Explanation: By not isolating the tests from real backend services, tests become vulnerable to network issues or changes in backend data, making them unreliable and flaky. Option B refers to UI performance, which is unrelated to backend communication. Option C is incorrect, as test scripts do not automatically skip execution for this reason. Option D, about form validation, does not connect to the use of mocks or stubs for API calls.

5. Verifying Function Calls

   In a test where you need to ensure a search function is called exactly once when a button is clicked, which technique would best help confirm this behavior?

   1. Setting up a stub that always returns errors
   2. Overwriting global variables
   3. Running the test without any test doubles
   4. Using a mock that records invocation counts

   Explanation: Mocks can track how often a function is called, making them ideal for verifying invocation counts or usage patterns. Stubs (option B) do not typically record how they are used, and always returning errors may not test the desired behavior. Running tests without test doubles (option C) prevents precise verification of function calls. Overwriting global variables (option D) is unrelated to tracking function invocations.