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

testing-logger

v6.0.0

Published

A logger specifically for use in test suites / harnesses.

Readme

testing-logger

A logger specifically for use in test suites / harnesses.

Example

This logger is designed for tests; it prints info & above and prints debugs if you set NODE_DEBUG=mylibrary

const TestingLogger = require("testing-logger");

const logger = new TestingLogger('mylibrary');

logger.debug('some fixed string', { some: 'meta object' });
logger.info('some fixed string', { some: 'meta object' });
logger.warn('some fixed string', { some: 'meta object' });
logger.error('some fixed string', { some: 'meta object' });

It writes all logs to stderr. If you call logger.error() or logger.fatal() it will throw exceptions. any error callsites are bugs.

warns go to stderr by default.

Using in tests

You can use the .whitelist() and .items() method to make testing easier

const TestingLogger = require('testing-logger');
const test = require('tape');

test('some module', function t(assert) {
  const logger = new TestingLogger('mything');
  const thing = new Thing({ logger: logger })

  logger.whitelist('error', 'some msg');

  thing.doStuff();

  const lines = logger.popLogs('some msg');
  assert.equal(lines.length, 1)
  assert.ok(lines[0].levelName, 'error', 'thing writes to logger.error()')

  assert.ok(logger.isEmpty())
  assert.end();
});

Whilst it is recommended that you minimize state between tests by creating a new instance of testing-logger, it is possible to remove a whitelisted item by calling .unwhitelist with the same arguments.

Interface

This library will re throw any .error() or .fatal() callsites.

Any warns and infos got to stderr.

Any debugs / access can be made visible using NODE_DEBUG=mylibrary.

You can turn colors off with --color false

If you want to see trace() logs you must set NODE_DEBUG=mylibrary TRACE=1

Alternatives

Warning: This a logger for testing! Not a default logger.

If you want to add a default logger to your dependencies then I strongly recommend you use null-logtron

Motivation

You want to instrument your application and your libraries with a production application logger. A logger that writes somewhere in production.

However for your writing tests for both your libraries and your applications you probably do not want to see all of your logs spewing on STDOUT by default.

This is where testing-logger comes in, You can start your app or libraries with the testing logger in your tests which allows the test runner to decide when to spew.

This works great together with itape --trace where you can use itape to turn on and off trace mode.

Docs

logger.whitelist(level, message)

This whitelisted a tuple of level and message, for example: logger.whitelist('warn', 'resetting connection')

This means that any callsites to logger.warn('resetting connection', { ... }) will not be printed to STDOUT.

If you call whitelist() in a test, it's expected you call popLogs()

logger.unwhitelist(level, message)

inverse, resets the whitelist if you have a logger shared among tests. ( dont do that.. )

logger.items()

Just returns every item that has been whitelisted from the logger, can be used for assertion purposes.

logger.popLogs(message)

This will return all log lines for that message ( including all levels ). This is a short hand for filtering items() by message.

Calling popLogs() will also decrease the internal counter used by isEmpty(). This can be used to make sure that test cases write assertions against everything that was logged.

logger.isEmpty()

Returns whether nothing was logged. Most of the time in tests you don't want anything to be logged to STDOUT.

If you do expect log callsites to get triggered ( info, warn, error, etc ) during tests then you can use whitelist() and popLogs().

You must call popLogs() to decrement the counter so that isEmpty() returns true.

This is especially useful if someone refactors the code by adding or removing loglines which will cause existing tests to fail ( either isEmpty() fails because popLogs() was not called for a new logline, or popLogs() fails because a logline was removed ).

Installation

npm install testing-logger

Tests

npm test

Contributors

  • Raynos

MIT Licensed