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

mocha-ddt

v0.0.3

Published

Data driven testing using Mocha.

Downloads

5

Readme

mocha-ddt

Data-Driven-Testing for Mocha

Build Status Coverage Status

Install and use

$ npm install mocha-ddt --save

Getting started

$ npm install mocha-ddt --save
$ mkdir test
$ $EDITOR test/test.js
$ $EDITOR index.js

In test.js:

var assert = require('chai').assert;
var mochaddt = require('mocha-ddt');

describe('Array', function() {
    describe('#indexOf()', function() {
        it('should return -1 when the value is not present', function() {
            var array = mochaddt.input(this, "array");
            var value = mochaddt.input(this, "value");
            assert.equal(array.indexOf(value), -1);
        });
    });
})

In index.js:

var mochaddt = require('mocha-ddt');
mochaddt.setTestDir("./test");
mochaddt.addTests(/#indexOf() should return -1 when the value is not present/, {
    input: {
        array: [1,2,3],
        value: 4
    }
});
mochaddt.run();

Features

input

input is used to retrieve inputs for running a set of test cases.

var some_var_name = mochaddt.input(this, "<INPUT_NAME>", <DEFAULT_VALUE>);

INPUT_NAME: Name of the input that you need. Refer to addTests.

DEFAULT_VALUE: Optionally give a default value. In case no input is specified when running test, default value will be used. It is encouraged to provide a default value, so that you can run tests using standard Mocha interface.

Example:

var mochaddt = require('mocha-ddt');
describe('country API', function() {
    var country = mochaddt.input(this, "country", "USA");
    describe('province API', function() {
        var province = mochaddt.input(this, "province", "CA");
        describe('city API', function() {
            var city = mochaddt.input(this, "city", "San Francisco");
            it(`can give me the location of ${city}`, function() {
                var config = mochaddt.input(this, "config", {});
                // You can use country, province, city and config here
            });
        });
    });
    
    describe('country overview API', function() {
        it(`can give an overview of ${country}`, function() {
            
        });
    });
});

As can be seen in the example, input can be used inside describe block and it block.

output, fetch

output is used inside a test case to output values, so that other test cases can use the output values.

fetch, on the other hand, is used to fetch the output from a test case.

Note that you can only fetch from a test case that is within the same describe block.

Example:

describe('account management api', function() {
    describe('functional test', function() {
        it('can create a new user', function() {
            var cuid = <api_call_to_create_user>.res.cuid;
            mochaddt.output(this, cuid);
        });
        
        it('can get the newly created user', function() {
            var cuid = mochaddt.fetch(this, "can create a new user");
            // ...
        });
        
        it('can put the newly created user', function() {
            var cuid = mochaddt.fetch(this, "can create a new user");
            // ...
        });
        // ...
    });
});

This certainly breaks the independency between test cases, but it is necessary sometimes especially for functional/E2E test suites. However, test cases in unit testing should remain independent and this feature shouldn't be used.

Calling API

mocha-ddt provides tools to send API requests.

Supported methods to call API

Synchronous API calls: getSync, putSync, deleteSync, postSync, patchSync, headSync, optionsSync

Asynchronous API calls (Promise based): get, put, delete, post, patch, head, options

Example of calling a GET API synchronously:

var options = {
    path: '/customers',
    headers: {
        <headerKey>:<headerValue>,
        //...
    },
    qs: {
        <queryKey>:<queryValue>,
        //...
    }
};
mochaddt.utils.getSync(options);

Options for API requests

You can specify an API request in either options or mochaddt.utils.

options:
  • path: A string. Path of API call. In case endPoint is not specified in mochaddt.utils, you need to put full URL here.
  • headers: key-value pair in JSON for headers.
  • qs: key-value pair in JSON for query parameters.
  • body: JSON object for body. You shouldn't specify body for GET, HEAD API calls.
mochaddt.utils:
  • endPoint: This is the end point for API calls. E.g. https://api.myserver.com/v1.2/
  • headers: Same as in options.
  • body: Same as in options.
  • qs: Same as in options.

Specifications in options apply only to 1 API call, whereas in mochaddt.utils, it is applied to all subsequent API calls.

headers, body and qs in options and mochaddt.utils will be deeply merged when calling an API through mochaddt.utils method. In case of conflict, values in options have priority. You should avoid conflict to prevent confusion.

If mochaddt.utils.endPoint is defined, endPoint and options.path will be combined

Environment