Monday, January 5, 2015

npm test (a sample case study of selected libraries)

What are people using as 'Test a package' script for their node packages ? I have taken several node modules from my test project and searched for scripts.test in their package.json.

Here is complete listing of script.test values from package.json files:

dreamopt             ./node_modules/.bin/mocha
json-diff            ./node_modules/mocha/bin/mocha
json-diff-patch      echo Error: no test specified && exit 1
wordwrap             expresso
when                 jshint . && buster-test -e node && promises-aplus-tests test/promises-aplus-adapter.js
json                 make test
printf               make test
qs                   make test
boom                 make test-cov
cryptiles            make test-cov
hawk                 make test-cov
hoek                 make test-cov
sntp                 make test-cov
entities             mocha && npm run lint
htmlparser2          mocha && npm run lint
domhandler           mocha -R list && jshint index.js test/
domutils             mocha test/tests/**.js && jshint index.js test/**/*.js lib/*.js
cli-color            node ./node_modules/tad/bin/tad lib
es5-ext              node ./node_modules/tad/bin/tad lib
jsdom                node ./test/runner
inherits             node test
marked               node test
json-stringify-safe  node test.js
oauth-sign           node test.js
sax                  node test/index.js
combined-stream      node test/run.js
form-data            node test/run.js
request              node tests/run.js
punycode             node tests/tests.js
open                 node_modules/mocha/bin/mocha
contextify           nodeunit test/
async                nodeunit test/test-async.js
cssstyle             nodeunit tests
xmldom               proof platform win32 && proof test */*/*.t.js || t/test
JSONStream           set -e; for t in test/*.js; do echo '***'  '***'; node ; done
through              set -e; for t in test/*.js; do node ; done
asn1                 tap ./tst
lru-cache            tap test
minimatch            tap test
glob                 tap test/*.js
graceful-fs          tap test/*.js
isarray              tap test/*.js
jsonparse            tap test/*.js
sigmund              tap test/*.js
readable-stream      tap test/simple/*.js
string_decoder       tap test/simple/*.js
http-signature       tap tst/*.js
tough-cookie         vows test.js

No test specified

25 modules have no test specified. It means they have no test or if they have it, you must read the manual how to run it.

tap (Test Anything Protocol tools for node)

11 modules uses tap.


7 modules uses mocha as their test runner. Also here are differencies, some people rely on global mocha installed, some use local node module.

dreamopt             ./node_modules/.bin/mocha
json-diff            ./node_modules/mocha/bin/mocha
entities             mocha && npm run lint
htmlparser2          mocha && npm run lint
domhandler           mocha -R list && jshint index.js test/
domutils             mocha test/tests/**.js && jshint index.js test/**/*.js lib/*.js
open                 node_modules/mocha/bin/mocha


8 uses make


1 uses vows - Asynchronous BDD & continuous integration for node.js

Linting as part of test process

5 uses linting as part of their test process, some more can be hidden in make files (TODO:)

when                 jshint . && buster-test -e node && promises-aplus-tests test/promises-aplus-adapter.js
entities             mocha && npm run lint
htmlparser2          mocha && npm run lint
domhandler           mocha -R list && jshint index.js test/
domutils             mocha test/tests/**.js && jshint index.js test/**/*.js lib/*.js

npm run lint and scripts.lint

Some projects also use scrpts.lint property in their package.json file.

This is arbitrary script and can be run with npm run lint

    lint: jshint index.js lib/*.js test/*.js,
    lint: jshint lib/*.js test/*.js test/*/*.js

Naming your test folder

test vs. tests vs. tst or even using directories: in package.json

test modules and devDependencies

Please do not put test harnesses or transpilers in your dependencies object. See devDependencies, below.

Most of used modules use this correctly anyway, for mocha and tap based project.

Other patterns seen

TODO: finish the texts

directories: {
  test: tests

// in domutils/package.json

Lessons learned

How npm handles the scripts field

Must read:

Flexible definition of test frameworks

  devDependencies: {
    tap: ,
  scripts: {
    test-tap: tap tst/*.js,
    test-mocha:mocha -R list .,

    test:npm run test-mocha

Combining test from multile steps

  "devDependencies": {
    "tap": "",
    "mocha": "",
    "nsp": "",
    "jshint": ""
  "scripts": {
    "test-tap": "tap tst/*.js",
    "test-mocha": "mocha -R list .",
    "lint": "jshint test/test.js",
    "test-security": "npm shrinkwrap && nsp audit-shrinkwrap",

    "test": "npm run test-mocha && npm run lint && npm run test-security"

This features also nsp, nodesecurity project, to check your dependencies for known vulnerabilities as part of test process.

tap vs. mocha vs. vows vs. ...

Currently I use mocha on my projects. Based on my dependency modules analyzed the tap seems more popular however.

In global mocha seems to be most popular an raising. see for charts: vows, tap and mocha

Wednesday, December 3, 2014


Watching some videos from Reject JS I have learned about plato: JavaScript source code visualization, static analysis, and complexity tool. Since this is my area of interest (one of and currently) I have started a small project, plato-reports and it took me several trials and errors to make a github hosted browsable copy here analysing npm (and other packages) using this tool. It produces some charts and metrics (avg shell be histograms, and loading of large project shell be faster) but: pictures are nice and metrics inspiring:

Wednesday, March 26, 2014

Dojo and usage of has()

Quote from: Browser sniffing and feature inference are flawed techniques for detecting browser support in client side JavaScript. So lets face the truth, dojo's own code base and how many time has(something) is used
62 "ie"
14 "quirks"
14 "dojo-sync-loader"
12 "webkit"
11 "extend-dojo"
10 "opera"
 9 "touch"
 9 "host-browser"
 7 "safari"
 7 "mozilla"
 7 "dojo-combo-api"
 5 "mac"
 5 "dom-addeventlistener"
 5 "dojo-trace-api"
 5 "bug-for-in-skips-shadowed"
 4 "ios"
 4 "highcontrast"
 4 "dom"
 4 "dojo-requirejs-api"
 4 "config-deferredInstrumentation"
 4 "chrome"
 3 'activex'
 3 "khtml"
 3 "host-rhino"
 3 "host-node"
 3 "ff"
 3 "dojo-v1x-i18n-Api"
 3 "dojo-preload-i18n-Api"
 3 "dojo-loader-eval-hint-url"
 3 "dojo-loader"
 3 "dojo-inject-api"
 3 "dojo-config-api"
 3 "config-useDeferredInstrumentation"
 3 "config-dojo-loader-catches"
 3 "android"
 3 "air"
 2 name
 2 'native-xhr'
 2 'config-dojoBlankHtmlUrl'
 2 "trident"
 2 "ie-event-behavior"
 2 "dom-qsa2.1"
 2 "dojo-unit-tests"
 2 "dojo-undef-api"
 2 "dojo-publish-privates"
 2 "dojo-log-api"
 2 "dojo-debug-messages"
 2 "dojo-cdn"
 2 "dojo-amd-factory-scan"
 2 "array-extensible"
 1 term
 1 'script-readystatechange'
 1 'native-xhr2'
 1 'native-formdata'
 1 'mozilla'
 1 'host-node'
 1 'host-browser'
 1 'dom-qsa2.1'
 1 'dom-parser'
 1 'dojo-force-activex-xhr'
 1 'config-useXDomain'
 1 'config-requestProvider'
 1 "wii"
 1 "rtl-adjust-position-for-verticalScrollBar"
 1 "position-fixed-support"
 1 "native-xhr"
 1 "json-stringify"
 1 "json-parse"
 1 "jscript"
 1 "events-mousewheel"
 1 "events-keypress-typed"
 1 "event-stopimmediatepropagation"
 1 "event-orientationchange"
 1 "event-focusin"
 1 "dom-quirks"
 1 "dom-qsa3"
 1 "dom-qsa"
 1 "dom-parser"
 1 "dom-matches-selector"
 1 "dom-compliant-qsa"
 1 "dom-attributes-specified-flag"
 1 "dom-attributes-explicit"
 1 "dojo-timeout-api"
 1 "dojo-test-sniff"
 1 "dojo-sniff"
 1 "dojo-moduleUrl"
 1 "dojo-modulePaths"
 1 "dojo-has-api"
 1 "dojo-guarantee-console"
 1 "dojo-force-activex-xhr"
 1 "dojo-fast-sync-require"
 1 "dojo-enforceDefine"
 1 "dojo-dom-ready-api"
 1 "dojo-config-require"
 1 "dojo-config-addOnLoad"
 1 "dojo-built"
 1 "css-user-select"
 1 "config-tlmSiblingOfDojo"
 1 "config-stripStrict"
 1 "config-selectorEngine"
 1 "config-publishRequireResult"
 1 "config-_allow_leaks"

Tuesday, March 11, 2014


Using iOS version 7.1 iOS >= 6.0. Safari and hybrid apps are supported. No they are not !!!

Sunday, January 5, 2014

jsPerf tests for split join replace

Today I have found this code in connect middleware: exports.normalizeSlashes = function normalizeSlashes(path) { return path.split(sep).join('/'); }; So I have immediately jumped to jsPerf and wanted to compare this to alternative methods (for speed). Unlucky as always, I have run into several nonsense tests:
  • - Both revisions 1,2 are wrong not comparing the same things
  • - another treasure
and we could you with the list. Again and again, broken tests and misleading measurements. Please all of you who run into this article, and write or use jsPerf results please read using-jsperf-correctly.

BTW: there is enough room for fiddling elsewhere. On of the tips: ""

Of course split/join is much slower then intuitive replace. At least with browsers and JSPerf

Update 2013-01-06:

Irony: I have authored BUGGY TEST AS WELL: and I hope fixed version 2 is better ;-)

Sunday, November 17, 2013

rvm and ruby for some beEF on OSX

There are many articles, some of them did not work for me and may not work for you… This is what I have made to succeed:

# uninstall all previous trials of rvm (modify .bash_profile and remove)
rm -rf .rvm*
# latest stable in my time was 2.0.0-p247
curl -L | bash -s stable --ruby
# obviously this install does not modify profile
source ~/.rvm/scripts/rvm
# just looking
rvm list known
ruby --version
# switch from apples version ruby 1.8.7 to "latest"
rvm use ruby-2.0.0-p247
rvm gemset create beef
rvm use ruby-2.0.0-p247@beef
# swich to cloned source 
cd ~/beef/
# make ruby in this folder to be 2.0.0
echo 'rvm use ruby-2.0.0-p247@beef' > .rvmrc
# install
bundle install

# run
source ~/.rvm/scripts/rvm
rvmsudo ./beef