Sinon Stub Framework (Sinon Re-export)

Common errors

• TypeError: Cannot read properties of undefined (reading 'restore')

  cause Attempting to call `.restore()` on a stub that was not properly created or has already been restored/garbage collected.
  fix Ensure the stub variable is correctly assigned the return value of `sinon.stub()` and that `restore()` is called only once per stub in an appropriate cleanup hook (e.g., `afterEach`). If using a `sinon.sandbox`, use `sandbox.restore()` instead.

• TypeError: myObject.myMethod is not a function

  cause Attempting to stub a method that does not exist on the object, or the object/method reference is incorrect at the time of stub creation.
  fix Verify that `myObject` and `myMethod` are correctly spelled and accessible at the point where `sinon.stub(myObject, 'myMethod')` is called. Ensure the method isn't being stubbed on an instance that's different from the one being tested.

Warnings

• breaking This package is effectively abandoned and has not been updated in approximately five years. It only re-exports the `sinon` library, meaning it offers no unique functionality and likely contains outdated versions of `sinon` (it currently depends on `sinon@^7.0.0`, while `sinon` is at v17+).
  Fix: Migrate all imports and dependencies directly to `sinon`. Uninstall `sinon-stub-framework` and install `sinon`.
• gotcha Because this package simply re-exports `sinon`, any breaking changes or API differences between `sinon` versions will apply. However, this wrapper will *not* automatically update `sinon` to its latest major versions, potentially leaving users stuck on older, unmaintained versions of `sinon`.
  Fix: Always use `sinon` directly to control your dependency version and benefit from the latest updates and documentation.
• deprecated The use of `require()` for CommonJS imports in modern Node.js environments is discouraged in favor of ES Modules (`import`). While `sinon` supports both, relying on an abandoned wrapper might complicate future migration or tooling integration.
  Fix: Switch to ES Module imports (`import { ... } from 'sinon';`) and use the `sinon` package directly. Ensure your project is configured for ESM.

Install

• npm install sinon-stub-framework npm
• yarn add sinon-stub-framework yarn
• pnpm add sinon-stub-framework pnpm

Imports

• stub
  wrong:

  import stub from 'sinon-stub-framework';

  correct:

  import { stub } from 'sinon-stub-framework';

  This package re-exports Sinon.js. For ESM, named imports are standard. This is equivalent to `import { stub } from 'sinon';`.
• Sinon
  wrong:

  const sinon = require('sinon-stub-framework'); // For older Node.js or CJS modules

  correct:

  import * as sinon from 'sinon-stub-framework';

  The entire Sinon module is re-exported. It's generally better to use the specific named imports you need, but this allows access to all Sinon utilities. For CJS, `const sinon = require('sinon');` is the direct equivalent.
• assert
  wrong:

  import { sinonAssert } from 'sinon-stub-framework';

  correct:

  import { assert } from 'sinon-stub-framework';

  Sinon's assertion utilities are directly available. This is equivalent to `import { assert } from 'sinon';`.

Quickstart

Demonstrates basic usage of Sinon stubs, showing how to replace a method's implementation, control its return values, and restore the original function after tests. This code is functionally identical to using `sinon` directly.

import { stub } from 'sinon-stub-framework';

class MyService {
  fetchData(id) {
    return Promise.resolve(`Data for ${id}`);
  }
  processData(data) {
    return data.toUpperCase();
  }
}

describe('MyService', () => {
  let myService;
  let fetchDataStub;

  beforeEach(() => {
    myService = new MyService();
    // Stub a method to control its behavior during tests
    fetchDataStub = stub(myService, 'fetchData');
  });

  afterEach(() => {
    // Restore the original method after each test
    fetchDataStub.restore();
  });

  it('should return stubbed data', async () => {
    fetchDataStub.returns(Promise.resolve('Mocked Data'));
    const result = await myService.fetchData(1);
    expect(result).toBe('Mocked Data');
    expect(fetchDataStub.calledOnceWith(1)).toBe(true);
  });

  it('should throw an error when stubbed', async () => {
    const errorMessage = 'Network Error!';
    fetchDataStub.throws(new Error(errorMessage));
    await expect(myService.fetchData(2)).rejects.toThrow(errorMessage);
    expect(fetchDataStub.calledOnceWith(2)).toBe(true);
  });

  it('should process data correctly even with stubbed dependency', () => {
    fetchDataStub.returns(Promise.resolve('raw data'));
    // Test another method that might rely on fetchData but we control its output
    const processed = myService.processData('another data'); // Assuming processData doesn't call fetchData here for simplicity
    expect(processed).toBe('ANOTHER DATA');
  });
});