Optional dependency wrapper mounting TAP as ddry test harness.
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
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'=dddriveit: '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
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
errorand 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);
ddryshell command to maintain the project spec config file
- test harness specific commands
ddry-tapetc. 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
- 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
devDependenciesset — ddry core and test harness(es) — to
- implementing harness-specific shell command, i.e.
Other three are
- ddry-mocha for Mocha JS;
- ddry-tape for Tape JS;
- ddry-mocha-tape mounting all the supported harnesses.
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 shell command delivers.
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.
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.
rs commands you can set and unset permanent only-except scopes that will affect running spec from within test harness.
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.
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.
-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
Feed to TAP any JS file of your choice and start ddry modular usage from
spec = require'ddry/modular'specapplytitle: '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.