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

rig-it

v0.0.3

Published

Test rig for writing reproducable integration tests in Node.js

Downloads

5

Readme

rig-it - The integration test rig!

Test rig for writing reliable, repeatable integration tests in Node.js

Sample code

This sample test is included in the project in folder ./samples. It tries to showcase most features of rig-it.

import expect from 'expect';
import { ConsoleReporter } from '../src/reporter/ConsoleReporter';
import { FileReporter } from '../src/reporter/FileReporter';
import { HtmlReporter } from '../src/reporter/HtmlReporter';
import { TestRig } from '../src/rig/TestRig';
import { TestRigRunContext } from '../src/rig/TestRigRunContext';
/**
 * Sample test running against the fake API at https://jsonplaceholder.typicode.com/
 *
 * For this to work, we need to perform some tweaks, e.g. expect a POST to return 201 but
 * the data won't be available at the reported id. The tweaks are pointed out in the comments.
 */

/**
 * Create the rig, giving it a name and specifying what test reporters you want to use. If no
 * reporters are specified, a {@link ConsoleReporter} will be used.
 */
const testRig = new TestRig({
  name: 'JSON Placeholder API',
  reporters: [
    new ConsoleReporter(),
    new FileReporter({
      testResponseFileNameResolver: (testId) => `sample-test-result/${testId}.json`,
      logsFileName: 'sample-test-result/logs.txt',
    }),
    new HtmlReporter({
      fileName: 'sample-test-result/logs.html',
    }),
  ],
});

testRig.run(async (testContext: TestRigRunContext) => {
  // Create a connector
  const connector = testContext.createConnector({
    baseUrl: 'https://jsonplaceholder.typicode.com',
    timeoutMs: 5000,
  });

  // If necessary for your use case, obtain credentials and set them on the connector.
  // const token = AuthProvider.getToken('username', 'password');
  // connector.setHeader('Authorization', `Bearer ${token}`);

  // Add your own customized log rows where necessary
  testContext.logger.info('Customized logging: Authentication succeeded!');

  // Create blog post
  const newPost = await testContext.test({
    id: 'create.post',
    act: async (ctx) => {
      return connector.post({
        url: '/posts',
        body: { title: 'foo', body: 'bar', userId: 1 },
      });
    },
    rigFailureTeardown: async (ctx) => {
      // If we end up here due to a test rig failure at some later point, the result from the act()
      // function is available in the context so we can delete the correct post
      const postId = ctx.response?.data?.id;
      await connector.delete({
        url: `/posts/${postId}`,
      });
    },
    rigSuccessTeardown: async (ctx) => {
      // You can also add customized logging here
      ctx.logger.success(
        `Customized logging: Tearing down create.post after success test rig run!`
      );
    },
  });

  // Establish the id of the new post, we need it for subsequent tests
  const postId = newPost.id;

  // Read back the post to make sure it's there (TWEAK! use id: 100 since we're using a mock API)
  await testContext.test({
    id: 'get.post',
    act: async (ctx) => {
      return connector.get({ url: `/posts/100` });
    },
    assert: async (ctx) => {
      expect(ctx.response?.data?.id).toBe(100);
    },
  });

  // We want deletion of the post to be part of the test as well, even though it's also deleted
  // on test rig failure.
  await testContext.test({
    id: 'delete.post',
    act: async (ctx) => {
      // Now it's no longer necessary to delete this post as part of failure teardown, so we remove it.
      // If we hadn't, that teardown step would have failed with a 404, but failures during teardown
      // are ignored, so any other teardown steps that were scheduled for execution would have been
      // carried out anyway.
      ctx.removeFailureTeardown('create.post');

      return await connector.delete({ url: `/posts/${postId}` });
    },
  });
});

Run the sample locally

> npm install
> npx ts-node ./samples/JsonPlaceholderTest.ts

If everything goes well, the results from the sample test will be available in folder ./sample-test-result