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 🙏

© 2026 – Pkg Stats / Ryan Hefner

ddry-tap

v10.3.2-d0.1.20

Published

Optional dependency wrapper mounting TAP as ddry test harness

Readme

ddry-tap

Build Status Coverage Status dependencies Status devDependencies Status

Optional dependency wrapper mounting TAP as ddry test harness.

Includes ddry v0.1.20 and TAP v10.3.2.

Version reflects TAP version, so your package.json remains clean yet informative.

ddry activity is reflected in semver pre-release area.

Few words about ddry

It made to remove all the error-prone code clutter from testing. No more fiddling with require target code modules for testing or assertion libraries. You simply (convention-over-configuration) organize your spec folder similar to your code folder, where module spec folder structure resembles module properties and methods structure, and in spec/someFolder/someModule/someMethod.js file you have the context of someMethod of someModule without any requiring — ddry does it for you seamlessly and transparently. Then (let's switch to coffee for even more awesomeness) in this way placed file

'use strict'

module.exports = (dd) ->
  dd.drive [
    it: 'does everything correctly'
    i: [ 'arguments', 'a', 'method', 'receives' ]
    e: 'value it returns'
  ]

And that's it. i is for input, e is for expected. Let's keep focused on data flow. Pray excuse me who think that require, assert, expect etc. are the essence of testing.

This data-driven code will be adapted and passed by ddry to any of three JS test harnesses: Mocha JS, TAP or Tape JS. ddry itself is fully covered on all of them with unified harness-agnostic codebase.

Also ddry has:

  • cross-harness features: context, before/after hooks and x-style skipping and mass-skipping;
  • powerful default matchers set including plain, contains and error and easy custom matchers adding;
  • spec sequence syntax allowing to use one setting through multiple specs;
  • convention-over-configuration folder-style module instances support;
  • easily configurable instantiable attachable spec helper;
  • Selenium Webdriver support (with Mocha only);
  • ddry shell command to maintain the project spec config file ddry.json;
  • test harness specific commands ddry-tap etc. to comfortly run the specs of your choice against test harness of your choice;
  • some cute minor features.

Plainly, a decent set of capabilities to make JS testing easy and even fun.

ddry command line interface

ddry CLI gives you convenient access to your data-driven specs by

  • keeping their config in ddry.json file;
  • implementing powerful features for maintaining this config file;
  • applying only-except style suite running scope with one shell command.

Only-except scoping logic is applicable to modules folders, modules and module methods levels.

In your development environment you may want to get easy access to ddry shell command by installing ddry globally:

$ sudo npm i -g ddry

ddry shell command is just a spec configuring tool, it does not perform any actual testing which is task of harness-specific commands as well as spec suite execution scoping. This package is one of four test harness specific ddry optional dependencies packages solving two main tasks:

  • adding viable devDependencies set — ddry core and test harness(es) — to package.json;
  • implementing harness-specific shell command, i.e. ddry-tap.

Other three are

You may consider globally installing them all with one package instead of playing with only-one-harness ones.

However, if you decided to use only TAP, easy access to ddry-tap command is obtained by installing this package globally:

$ sudo npm i -g ddry-tap

Spec suite configuring tool

Well, we have devDependencies installed and set of shell commands. Now you can start your ddry.json file with $ ddry i (init) command. It is very easy and welcoming and has quite comprehensive documentation accessible via $ ddry ? i command.

Then you can populate your spec folder with data-driven specs and adjust ddry.json file for running specs from within TAP. Just pass to it the ./node_modules/ddry/ddry.js file. Please check Makefile of this project for examples for every supported test harness.

ddry.json contains full information on data-driven testing of the project. It may have or may not have advanced configuration options which are subject to ddry core documentation. Anyway, whatever comfort you may have in addition to editing ddry.json manually, ddry shell command delivers.

With config or c command you can plug your own JS module receiving arguments and returning the config object you need. That is how config editing automation is solved here.

With titles or t command you can parse your code folder for module titles taken from the first block comment. Also this command builds the system file cli.json used for spec suite execution scoping. If scoping fails, ddry t will fix it likely.

With addScope or as and removeScope or rs commands you can set and unset permanent only-except scopes that will affect running spec from within test harness.

With add or a and remove or r commands you can add and remove values of config object. These two commands are rather for compatibility, scoping commands described above or manual editing of ddry.json look much more appropriate.

usage or ? or h command outputs usage info — summary or for given command. We don't need to reproduce it here.

Spec suite execution scoping

ddry-tap without parameters will launch the entire suite configured in ddry.json against TAP.

Use -e and -o keys for except and only scoping strategies applied to tab-completed code or spec files or folders. Inside code folder you have access to module folders and module level, inside spec folder you may scope method-wise. Keys you use with ddry-tap command will have effect only once, while this shell command runs.

As mentioned above, to manage permanent scopes in ddry.json you may use $ ddry as and $ ddry rs commands — they will translate to config object style (dot-notated, by the way) your tab-completed findings.

Programmatical usage

(obsolete)

Feed to TAP any JS file of your choice and start ddry modular usage from

spec = require('ddry/modular')()
spec.apply
  title: 'Your awesome module'
  code: 'lib'
  spec: 'spec'

or even ultimately superlatively obsolete basic plain usage:

DataDriven = require 'ddry'

But I think you really want CLI for actual work. Editing the spec config in and out for use-once scopes is as boring to death probably as grep-ping around your tests.