npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

fraudster

v1.1.0

Published

Simple mocking of require statements in Node

Downloads

1,923

Readme

#fraudster

Simple mock injection for Node require statements

Fraudster is not a mocking framework, it just allows you to inject your mock / fakes / stubs inplace of what would usualy be loaded by require calls.

Why

I have been using mockery heavily for some time.

I like how it works, but have always wanted to change a few things it seams to be not maintained any more.

The main thing I needed merged was making it instanceable so that mocks do not leak into other tests...

This module is heavily based on that code but I have simplified a few things.

Install

npm i fraudster

Usage

var Fraudster = require('fraudster'),
    fraudster = new Fraudster(),
    fakeFs = {
        exists : function(path, callback){
            // Calls to fs.exists will always return true
            callback(null, true);
        }
    };

fraudster.registerMock('fs', fakeFs);

var fs = require('fs'); // Real fs module

fraudster.enable();

var fakeFs = require('fs'); // Fake fs module

fraudster.disable();

Options

When constructing Fraudster you can pass an optional options object to enable / disable warnings and errors

var Fraudster = require('fraudster'),
    fraudster = new Fraudster({
        warnOnUnregistered: true,
        errorOnUnregistered: true,
        warnOnReplace: true,
        errorOnReplace: true,
        cleanCacheOnDisable: true // default false
    });

If warn is enabled a warning will be logged to the console, if error is enabled an Error will be thrown

When cleanCacheOnDisable is true the modules that were required while fraudster was enabled will be removed from cache on disable/deregisterAll

Registering mocks

Register mocks to make them available when Fraudster is enabled

var fakeFs = {
    exists : function(path, callback){
        // Calls to fs.exists will always return true
        callback(null, true);
    }
};

fraudster.registerMock('fs', fakeFs);

If you no longer want your mock to be used, you can deregister it:

fraudster.deregisterMock('fs');

Allowable modules

If you enable Fraudster load a module that has not been mocked, Fraudster will by default log a warning to the console. This is so that you don't inadvertently use downstream modules without being aware of them. By registering a module as "allowable", you tell Fraudster that you know about its use, and are happy for the original module to be loaded.

The most common use case for this is your source-under-test, which obviously you'll want to load without warnings. For example:

fraudster.registerAllowable('./my-source-under-test');

You can also register many allowables at once with registerAllowables

fraudster.registerAllowables(['./my-source-under-test', './someOtherModule']);

If you later want to remove an allowable this can be done as below

fraudster.deregisterAllowable('./my-source-under-test');

or

fraudster.deregisterAllowables(['./my-source-under-test', './someOtherModule']);

Deregistering everything

If you just want to destoy all the things you can use the deregisterAll method

fraudster.deregisterAll();