node package manager

ddry-mocha-tape

ddry-mocha-tape

Build Status Coverage Status dependencies Status devDependencies Status

ddry logo

Mounts three test harnesses and three test utility modules to ddry. It's hardly believable that you'll ever need this setup, it is for testing ddry itself mostly.

Includes:

Anyway, this powerful setup enables this module to be used in ddry as only devDependency.

Version reflects ddry version.

Few words about ddry

It is 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 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 all three test harnesses — to package.json;
  • implementing harness-specific shell commands ddry-mocha, ddry-tap and ddry-tape.

Other three are

Easy access to ddry-mocha, ddry-tap and ddry-tape commands is obtained by installing this package globally:

$ sudo npm i -g ddry-mocha-tape

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 the test harness of your choice. 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-<mocha|tap|tape> without parameters will launch the entire suite configured in ddry.json against its harness.

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 the test harness 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.