Gathering detailed insights and metrics for stories
Gathering detailed insights and metrics for stories
Gathering detailed insights and metrics for stories
Gathering detailed insights and metrics for stories
npm install stories
Typescript
Module System
NPM Version
70.9
Supply Chain
99.3
Quality
75.3
Maintenance
100
Vulnerability
100
License
JavaScript (100%)
Total Downloads
12,056
Last Day
3
Last Week
10
Last Month
52
Last Year
6,505
MIT License
1 Stars
26 Commits
1 Watchers
1 Branches
1 Contributors
Updated on Dec 26, 2014
Minified
Minified + Gzipped
Latest Version
1.0.5
Package Id
stories@1.0.5
Size
5.34 kB
NPM Version
1.2.18
Cumulative downloads
Total Downloads
Last Day
0%
3
Compared to previous day
Last Week
233.3%
10
Compared to previous week
Last Month
-40.9%
52
Compared to previous month
Last Year
987.8%
6,505
Compared to previous year
Lightweight Given/When/Then/And/But blocks with async-support for Node.js.
Node-stories uses the same kind of metaprogramming most other JavaScript testing suites are using. A silly example:
process.mixin(require('./story'));
new Feature('Using an Array as a queue', function () {
var assert = require("assert");
Given('An empty Array', function () {
a = []
})
When('I add some elements', function () {
a.push(1)
a.push(2)
a.push(3)
a.push(4)
})
And('I shift an element off the Array', function () {
element = a.shift()
})
Then('I should get the first element from the Array', function () {
assert.equal(element, 1)
})
And('I should have the remaining elements left', function () {
assert.equal(a.length, 3)
})
But('I should not have the shifted element left', function () {
a.forEach(function (e) { assert.notEqual(e, element) })
})
})
Now when you run this:
node my_feature.js
Then you should see in your terminal:
Feature: Using an Array as a queue
Given An empty Array
When I add some elements
And I shift an element off the Array
Then I should get the first element from the Array
And I should have the remaining elements left
Obviously, this is colorized and always displays the errors together with each failing step.
Node-story has a human-readable DSL for deferring evaluation of steps until a step specifying asynchronous behavior has completed or, optionally, timed-out. Nothing of this pollutes the global namespace and node-stories uses some fancy accessor trickery to keep things readable:
Define how many passes
are expected:
await(5).passes
await(1).pass
Optionally you can define a timeout (in milliseconds):
await(6).passes.withTimeout(2500)
Emit a passed test:
passed
Emit a failed test:
failed
Note: failed
will automatically display the error object passed to the
callback, eg. by addErrback()
, and display.
Using the async helpers, node-stories will synchronously run your features:
new Feature('A passing, async feature', function () {
var emitter;
Given('An event emitter', function () {
emitter = new process.EventEmitter()
})
And('A timed, emitted success', function () {
setTimeout(function () { emitter.emit('success') }, 1500)
})
Then('This step will wait until the block has finished', function () {
await(1).pass
emitter.addListener('success', function () {
passed
})
})
And("This step won't run any earlier", function () {
// Do some more assertions here.
})
})
Have a look into the examples/
directory (which, before you ask, are also used for
testing node-stories).
Deep nesting is currently not supported by node-stories. A Feature should describe one thing in the most concise way possible and deep nesting should not be neccessary. At least that is my style. However, if you fancy support for nesting, feel free to fork and send me a pull request.
Node-stories is matcher independent. You can use Node's built-in assert
module or the matchers of your favorite unit-test/spec suite. As long as they
throw errors on failed assertions, just like the assert
module, everything
(the console output) should be fine.
I wrote this so I can add some simple integration tests to some of the projects I am currently working on. However, feature requests and contributions are of course welcome.
Copyright (c) 2009 Tobias Svensson (tobiassvn@googlemail.com)
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
No vulnerabilities found.
Reason
no binaries found in the repo
Reason
0 existing vulnerabilities detected
Reason
license file detected
Details
Reason
no SAST tool detected
Details
Reason
Found 0/26 approved changesets -- score normalized to 0
Reason
0 commit(s) and 0 issue activity found in the last 90 days -- score normalized to 0
Reason
no effort to earn an OpenSSF best practices badge detected
Reason
security policy file not detected
Details
Reason
project is not fuzzed
Details
Reason
branch protection not enabled on development/release branches
Details
Score
Last Scanned on 2025-05-05
The Open Source Security Foundation is a cross-industry collaboration to improve the security of open source software (OSS). The Scorecard provides security health metrics for open source projects.
Learn More