Are you happy with your logging solution? Would you help us out by taking a 30-second survey? Click here


:tropical_drink: Mock all of your ES6 module components with Mocktail using dependency injection.

Subscribe to updates I use Mocktail

Statistics on Mocktail

Number of watchers on Github 95
Number of open issues 3
Average time to close an issue 2 days
Main language JavaScript
Average time to merge a PR about 17 hours
Open pull requests 0+
Closed pull requests 0+
Last commit almost 4 years ago
Repo Created about 4 years ago
Repo Last Updated over 1 year ago
Size 1.24 MB
Homepage http://mocktail.h...
Organization / Authorwildhoney
Page Updated
Do you use Mocktail? Leave a review!
View open issues (3)
View Mocktail activity
View on github
Fresh, new opensource launches 🚀🚀🚀
Trendy new open source projects in your inbox! View examples

Subscribe to our mailing list

Evaluating Mocktail for your project? Score Explanation
Commits Score (?)
Issues & PR Score (?)


Mock all of your ES6 module components with Mocktail using dependency injection.

Travis   npm   License MIT

  • npm: npm i mocktail -D


Getting Started

:ice_cream: Watch Getting Started with Mocktail:

Mocktail encourages developers to stub at runtime — dependency injection — when writing their tests – for this mocktail provides the mock method.


import {mock} from 'mocktail';

class Request {}

export default mock(Request);

By default the mock method in the case above will return the actual Request object when imported. However, when unit testing you'll define the environment as ENV.TESTING using the env method in your setup file. In the same file you can specify an alternative for the Request object by specifying its RequestMock instead:


import {env, ENV, inject} from 'mocktail';

inject('Request', RequestMock);

Note: The Request name is specified as a string to the inject method, which is deduced from the actual Request object using its name property:

Now whenever you import the Request module in your unit tests — assuming you import after you have imported your setup file — then the returned object will be RequestMock rather than Request.


import 'Setup';
import Request from 'Request';


Seldom you may wish to stub in your module itself – in these cases pass it through mocktail.stub passing in both the actual object and its associated stub object:


import {stub} from 'mocktail';

class Request {}
class RequestMock {}

export default stub(Request, RequestMock);

With the stub method, the second argument is always the stubed object that will be returned when environment is defined as true using:


import {env, ENV} from 'mocktail';

In the above example the default value for environment is ENV.PRODUCTION and can be set explicitly with: env(ENV.PRODUCTION).

With Mocktail it's important to note that the import syntax is exactly the same whether you're importing the actual object or its stubed counterpart.

Named Export

Often you may want to export your modules without exporting as the default – in these instances you can use the export as syntax:


import {mock} from 'mocktail';

class Request {}
class RequestMock {}

const Module = mock(Request, RequestMock);
export {Module as Request};

Then when you import the module elsewhere, you simply refer to the import as Request, which could either be the true Request object, or its stub – RequestMock:


import {Request} from './Request';


Setting up Mocktail is straightforward – with the easiest way being to have a setup file that is loaded before your unit tests are run.


import {env, ENV} from 'mocktail';

You then need to ensure that your setup file is loaded prior to the loading of your components:


import './Setup';
import Request from '../components/Request';

describe('Request', () => {
    it('Should provide RequestMock', () => {

Any time the Request component is imported, it will be the stubed counterpart as opposed to the actual object – which in the case of Request objects would simply mimic an AJAX call using a delay.

You can take a look in the example directory for the recommended setup for Mocktail.

Comparing Proxyquire

Note: See Discussion.

Proxyquire is a useful tool in importing mocks for your tests – so much so that it may seem futile to use Mocktail. However, the advantages of Mocktail are apparent when you consider a project.

Assume you have the following project:


export default class Request() {}


import Request from './Request';

With the proxyquire approach the Flickr.js file would still be holding the actual Request object that makes live AJAX requests – when testing this would be undesirable. Therefore with the Mocktail approach, Flickr.js would instead be holding a RequestMock object that simply waits for an arbitrary amount of time and then either resolves or rejects the promise – and this is the crucial difference between the two approaches.

If you wanted to make proxyquire behave as Mocktail does, then your Flickr.js file would need to proxyquire the Request object as well, which leads to polluting your code with test-specific code – with Mocktail the test-specific code is isolated to only the files you wish to mock and/or stub.


Pull requests are highly encouraged if you find any bugs, or wish to improve the codebase with wonderful ideas. However, if you're a little shy, please feel free to open an issue – that is fine, too.

Tests are written in Karma and can be run with npm run test after you have installed all dependencies with npm i.

Mocktail open issues Ask a question     (View All Issues)
  • over 3 years Mocking builtin or libraries?
  • over 3 years Error when importing `inject` from 'mocktail'
  • about 4 years The comparison to proxyquire doesn't mention noCallThru
Mocktail questions on Stackoverflow (View All Questions)
  • iOS - using mocktail while sublcassing NSURLProtocol
  • How to Get Mocktail to Accept URL Parameters
Mocktail list of languages used
Other projects in JavaScript