Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stubbing default exported functions #1623

Closed
sebakerckhof opened this issue Nov 16, 2017 · 2 comments
Closed

Stubbing default exported functions #1623

sebakerckhof opened this issue Nov 16, 2017 · 2 comments
Labels
ES2015+ ES2015 and later revision

Comments

@sebakerckhof
Copy link

It is a common use case to mock ES modules.

e.g. I have a module that imports getEventByEventId

import getEventByEventId from '../queries/getEventByEventId';

export default async (
  {
    connection,
    session
  }: ResolverContextType
) => {
  if (!session || !session.userId) {
    throw new Error('User must be authenticated.');
  }

  const event = await getEventByEventId(connection, eventId);

  // ..
}

In my test I want to mock getEventByEventId, e.g.

import test from 'ava';
import sinon from 'sinon';
import moment from 'moment';
import createReservation from '../../../src/mutators/createReservation';

test('throws an error if the event is in the past', async (t) => {
  const parameters: any = {};

  const context: any = {
    session: {
      userId: 1
    }
  };

  const stub = sinon.stub().returns({
    date: moment().format('YYYY-MM-DD'),
    time: moment(new Date().getTime() - 1000 * 60).format('HH:mm')
  });

  // How to use the stub to mock `getEventByEventId`?

  await t.throws(createReservation(context), 'Cannot create a reservation for a past event.');
});

This was asked before here: #1358 . But this got unrightly closed as a duplicate of: #1121 , while it is a totally different issue.
This was already mentioned in that issue, but it doesn't seem to get looked after anymore.

@mroderick
Copy link
Member

Sinon.JS does not concern itself with module systems. I am closing this.

Because of the many requests that keep coming in, and that the stewards of the project also write tests for a living, we have published How To Use Link Seams With CommonJS.

Please help us keep the issues list manageable and ask usage questions on the Sinon.JS users mailinglist or StackOverflow. Both are good resources where the wider audience of users can offer help.

fatso83 added a commit that referenced this issue Feb 28, 2018
Ref #1711 and #1623 for background.

This feature is simply about throwing a meaningful error, instead
one that tells the user that the property cannot be deleted. As
the exports from ECMAScript modules are immutable once created we
cannot do anything about them from the view of Sinon, so it's
preferable to simply tell the user that when we can.

This should not affect transpiled code (say, using Babel), as the
resulting modules are no longer true ECMAScript modules (but rather
some form of CommonJS module).
fatso83 added a commit that referenced this issue Mar 5, 2018
Ref #1711 and #1623 for background.

This feature is simply about throwing a meaningful error, instead
one that tells the user that the property cannot be deleted. As
the exports from ECMAScript modules are immutable once created we
cannot do anything about them from the view of Sinon, so it's
preferable to simply tell the user that when we can.

This should not affect transpiled code (say, using Babel), as the
resulting modules are no longer true ECMAScript modules (but rather
some form of CommonJS module).
@fatso83 fatso83 added the ES2015+ ES2015 and later revision label Sep 7, 2018
@nikoremi97
Copy link

@sebakerckhof checkout this #562 (comment)

franck-romano pushed a commit to franck-romano/sinon that referenced this issue Oct 1, 2019
Ref sinonjs#1711 and sinonjs#1623 for background.

This feature is simply about throwing a meaningful error, instead
one that tells the user that the property cannot be deleted. As
the exports from ECMAScript modules are immutable once created we
cannot do anything about them from the view of Sinon, so it's
preferable to simply tell the user that when we can.

This should not affect transpiled code (say, using Babel), as the
resulting modules are no longer true ECMAScript modules (but rather
some form of CommonJS module).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ES2015+ ES2015 and later revision
Projects
None yet
Development

No branches or pull requests

4 participants