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

tun-test-automation-core

v0.0.80

Published

Probably the best test framework in the world

Readme

Installation requirements

  1. Node.js
  2. Visual Studio Code

Installation

  1. Clone this project/repository
  2. Run npm install in the root folder

How to execute internal tests

Gherkin tests (Web UI tests) - Command Line

Run node_modules\.bin\wdio tests\gherkin\wdio.conf.js

Mocha tests (intended for REST API integration testing) - Command Line

Run node_modules\.bin\mocha tests\Mocha\features\*.js

WDIO Configuration usage

We use the WebdriverIO cucumber test runner for when executing web tests.
The wdio executable expects a wdio config file as first argument (as seen in the Gherkin test example above).

Tunstall internals

debug - set this to true in order to activate WDIO debug mode

Example usage:

const debug = process.env.DEBUG;

WDIO debug documentation:
http://webdriver.io/guide/testrunner/debugging.html
http://webdriver.io/api/utility/debug.html

defaultTimeoutInterval - the time that Selenium Webdriver will wait for an element to meet a certain state (e.g. visible, hidden)

Example usage:

const defaultTimeoutInterval = 20 * 1000;

Selector usage for WDIO web tests

All of the keyActions that are exposed for external usage require that selectors have been registered as global.selectors at startup.

A selector is simply a HTML DOM element that is part of a browser web application. These elements can be identified in many ways, e.g. by id, className, cssSelector and xpath. A selector can be a button, input field, a paragragh, anything that's part of a web page.

The main way of registering the selectors that we want to use is by creating a data folder in your root project folder, followed by a selectors folder. In this folder you may add .js files with any name and within any folder hierarchy.
The idea of having seperate files is that you should be able to separate or structure your selector content, avoiding to have everything in one file.

Lets assume you have 1 file named home-page-selectors.js which holds this json data:

[
  {
    "name" : "white submit button",
    "selector" : "#whiteButton",
    "text" : 'Submit'
  },
  {
    "name" : "username field",
    "selector" : "#username",
    "text" : null
  }
]

The files within \data\selectors aren't magically assigned to the global.selectors variable by itself. You simply need to make us of the dataSelectorParser.js to make this happen.
Example implementation from an external project:

const tunstallCore = require('tun-test-automation-core');
tunstallCore.clients.web.dataSelectorParser.loadAtStartup('/path-to-/data/selector/-folder', (done) => {
    console.log("global.selector setup done");
});

The above example implementation ensures that all json/selectors from the /data/selectors/ (and beyond) are parsed and concatenated into a single array of selectors - an array which is assigned to the global global.selectors variable.

The core keyActions take selectorName's as arguments. For instance, if we make use of the example selectors mentioned above, an implementation would look like this:

  • Clicking on an element:
    tunstallCore.clients.web.click('white submit button');

  • Writing a value in an element:
    tunstallCore.clients.web.write('my text', 'username field');

The methods take the "friendly" selector name as a parameter and map this to the actual element selector.
The click will in this case pull a selector from global.selectors that has the name white submit button and click on its selector, #whiteButton.
The write function will enter the text "my text" in the #username selector, belonging to "username field".

We make use of a "friendly name" in our selector data so that we can write gherkin tests that make sense.
A tester is able to create a test case and write Then I click on the google search button whereas the google search button is a dynamic parameter that exists as a selector in the project specific selector data (/data/selectors/).

Todo list

  • [ ] Add a test case that uses image comparision (Visual Regression service)
  • [ ] Use Selenium Grid?
  • [ ] Determine which report services to use (for Mocha and Gherkins/Cucumber)
  • [ ] Add an Android App test case (Gherkins)
  • [ ] Add an iOS App test case (Gherkins)