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 🙏

© 2024 – Pkg Stats / Ryan Hefner

nock-back-ci

v1.0.0

Published

A simple acceptance testing helper optimised for complex CI problems

Downloads

11

Readme

nock-back-ci

Build Status Coverage Status

A simple acceptance testing helper optimised for complex CI problems

Motivation

As responsible developers we want to test our NodeJS services with acceptance tests to simulate real traffic.

In a continuous deployment environment, the CI pipeline should be able to run those acceptance tests, however, the deployment of our service shouldn’t depend on an external service being up and running. Moreover, to run our service, we may need to access other services that are not reachable from the CI pipeline.

Solution

When the acceptance tests are run in local, they will query the real external services. During this run, the responses of all the external http calls will be stored in a fixture file.

When the tests are run in the CI pipeline, instead of querying the external services, we will use the mocked responses stored in the fixture file.

This process will be transparent for the developers maintaining the tests.

Usage

For a complete working example check examples/server.test.js.

const NockBackCI = require('nock-back-ci');
// appProvider is an awaitable function that returns your express app
const appProvider = require('./yourapp');

// The localEnvironment flag should be set to true when the environment is local
// and false in the CI environment. This is usually done via environment variables.
const nockBackCiConfig = {
  localEnvironment: true,
  fixtureName: 'exampleFixture.json',
  fixtureDir: path.join(__dirname, 'fixtures'),
};

const nockBackCI = new NockBackCI(nockBackCiConfig);
const server = await nockBackCI.bootServer(appProvider); // server is an instance of supertest request

const testCase = await nockBackCI.testCaseInit();

// Test your api here

nockBackCI.testCaseEnd(testCase);
nockBackCI.killServer(server, done);

Tip: For the best experience place the usage of nock-back-ci in the before/after jest functions. Check the examples/server.test.js example for inspiration.

Extra options

const nockBackCiConfig = {
  localEnvironment: true,
  fixtureName: 'exampleFixture.json',
  fixtureDir: path.join(__dirname, 'fixtures'),
  whitelistedHosts: /(localhost|127\.0\.0\.1|kms.amazonaws)/,
  healthcheck: '/operations/healthcheck', // The test won't start until this endpoint replies a 200
  customFilter: (scope) => true,
};

Custom filters

In order to avoid recording specific responses in the fixtures depending on their content, the customFilter extra option becomes handy.

For example, the following custom filter would avoid recording empty responses to the fixture file:

const nockBackCiConfig = {
  customFilter: (scope) => scope.response,
}

Security

Keep in mind that nock-back-ci will record ALL http calls made by your service by default.

Please take care if your application sends or receives sensitive information like credentials, access keys, or users' personal information so that these data are not committed to your repository inside the fixutes.

To skip nocking for a particular endpoint, add it with the whitelistedHosts option to the nock-back-ci config like the example above.

API Warmup

In some cases, starting the api and having it ready to serve traffic may take a while. This is usually the case when it queries external services and warms up caches.

If this is your case, by providing an optional healthcheck parameter the test won't start until the healthcheck of the api becomes green.

Moreover when using this functionality, a separate fixture named boot.json will be created to store the http responses of the services queried at startup time.

Todo

Items on the roadmap.

  • Add tests to the lib/options file
  • Feature: When to recreate local fixtures policy
  • Feature: Config validation

Contributing

See the CONTRIBUTING.md file.

License

MIT License (c) 2018 Joan Vilà Cuñat