Sinon Mocks & Spies Essentials in Mocha Testing Quiz

Explore core concepts of mocking and spying using Sinon in Mocha for effective unit testing, including spy behaviors, mock usage, expectation handling, and proper teardown techniques. This quiz helps reinforce best practices and clarify misconceptions for reliable test suites involving test doubles.

1. Understanding Sinon Spies

   In a unit test, which statement correctly describes a primary use of a Sinon spy when applied to a function?

   1. It records all calls and arguments to a given function without modifying its behavior.
   2. It replaces the function implementation with a mock version.
   3. It prevents the function from being called.
   4. It asserts that the function has a fixed return value.

   Explanation: A spy records how a function is called, tracking arguments, call counts, and context, without interfering with its actual implementation. Replacing or mocking the implementation is the domain of stubs and mocks, not spies. Spies do not block function execution and do not set or enforce a specific return value; they simply observe and record call activity.

2. Sinon Mocks in Action

   When using Sinon mocks in a Mocha test, what is the key advantage of mocks over stubs in applying expectations?

   1. Mocks allow you to define and verify specific expectations about function calls.
   2. Mocks execute the original function implementation instead of replacing it.
   3. Mocks automatically restore the original function after the test completes.
   4. Mocks do not record how many times a function was called.

   Explanation: Mocks let you set explicit expectations, such as the number of calls and argument values, and verify these expectations during or after the test. Unlike mocks, stubs typically replace function behavior but don't enforce expectations. Mocks do not automatically restore functions — they require manual restoration — and they do track calls made, unlike what one distractor suggests.

3. Spy Call Arguments Inspection

   How would you verify in a Mocha test that a spied function was called with specific arguments using Sinon?

   1. By using the spy.calledWith(expectedArgs) method.
   2. By overwriting the spy's implementation.
   3. By checking the function's return value only.
   4. By invoking the spy.restore() method.

   Explanation: The spy.calledWith method directly checks if the spy observed a call with particular arguments, making it the correct approach. Overwriting the implementation is not necessary for argument inspection. Checking return values does not reflect how or with what arguments the function was called. The restore method is unrelated to call argument verification.

4. Resetting Test Doubles

   After creating spies and mocks with Sinon in a test suite, why is restoring or resetting them important at the end of each Mocha test?

   1. To prevent side effects or leaks between test cases.
   2. To speed up the execution of the tests.
   3. To increase the number of assertions automatically.
   4. To execute code outside the test's context.

   Explanation: Restoring or resetting ensures that instrumentation on functions does not persist between tests, avoiding interference and making tests reliable. Test speed is not directly impacted by not resetting. Assertion count is not increased by restoring or resetting doubles. Running code outside the test context is unrelated.

5. Mock Expectation Failures

   What typically happens in a Mocha test if a Sinon mock’s expectation is not met during test execution?

   1. The test fails, indicating which expectation was not satisfied.
   2. The mock automatically passes the expectation.
   3. The test runner skips further assertions silently.
   4. The function being mocked executes twice as a warning.

   Explanation: If a mock's expectation is violated, the test fails with a clear message about the unsatisfied expectation, ensuring visibility of the issue. Mocks never auto-pass unmet expectations. Skipping assertions or doubling function executions is not standard behavior in response to unmet mock expectations.