stdlib-js / stdlib-js/stdlib

[RFC]: Migrate from tape to in-house @stdlib/test/harness

Open
#10,365 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
JavaScript
Stars
6k
Forks
1.3k
Avg merge
1d 3h
Merged PRs (30d)
611

Description

Description

This RFC proposes

Proposal: Migrate stdlib Tests to In-House @stdlib/test/harness

This proposal delivers a tape-equivalent in-house test runner as @stdlib/test/harness, directly porting its minimal TAP API while matching @stdlib/bench/harness patterns. It eliminates the tape dep, supports only stdlib's used assertions (equal, strictEqual, ok, deepEqual, pass, fail, plan, end, test), and adds @stdlib/string/format interpolation—no parallelism, grouping, or extras like mocha/jest.

Before/After Test File

Before (tape):

'use strict';

var tape = require( 'tape' );
var foo = require( './../lib' );

tape( 'main export is a function', function test( t ) {
	t.ok( true, 'should be true' );
	t.strictEqual( typeof foo, 'function', 'main export is a function' );
	t.end();
});

tape( 'computes correctly', function test( t ) {
	t.plan( 2 );
	t.equal( foo( 3 ), 9, 'returns 9' );
	t.deepEqual( foo(  ),, 'deep equal' );[1][2][3]
	t.end();
After (@stdlib/test/harness):

After (@stdlib/test/harness):

```javascript
'use strict';

var test = require( '@stdlib/test/harness' );
var foo = require( './../lib' );

test( 'main export is a function', function test( t ) {
	t.ok( true, 'should be true' );
	t.strictEqual( typeof foo, 'function', 'main export is %s', 'function' );
	t.end();
});

test( 'computes correctly', function test( t ) {
	t.plan( 2 );
	t.equal( foo( 3 ), 9, 'returns %d', 9 );
	t.deepEqual( foo(  ),, 'deep equal' );[1][2][3]
	t.end();
});

Changes: Swap require('tape')require('@stdlib/test/harness'). Assertions identical—no renames/refactors. Interpolation optional (%s/%d/%j via @stdlib/string/format).

Study of References

Reviewed tape source (tape-testing/tape): TAP stream via events, nested tests, async end(), assertion tracking. Compared to @stdlib/bench/harness: Similar b.bench()/test(), exports harness/stream factory, stdout TAP—no deps. Stdlib tests (e.g., Makefile/package.json scans): Use ~6 assertions max, plain TAP, no advanced tape features. Impl ports tape's core (test context, assert/incr count, TAP lines) to ~400 LOC Node streams.

Automation Strategy

  • Publish @stdlib/test/harness (bench mirror: libtests, Makefile).
  • Global replace: grep -rl "require('tape')" lib/ | xargs sed -i "s|require('tape')|require('@stdlib/test\/harness')|g" (handles escapes).
  • Glob run: Update stdlib Makefile: $(QUIET) $(NODE) $(TOOLS_DIR)/harness.js $(shell find lib -name 'test.*.js').
  • Validate: CI diff old/new TAP (tape | harness); fix interpolation mismatches via optional post-sed (regex scan t.equal/ok args).
  • Coverage: Stick with istanbul (nyc/c8 drops Node 10-12 compat).
Related Issues

[Idea]: develop a project test runner

Questions

No.

Other

No.

Checklist
  • I have read and understood the Code of Conduct.
  • Searched for existing issues and pull requests.
  • The issue name begins with RFC:.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reading the proposed @stdlib/test/harness alongside the existing @stdlib/bench/harness patterns, then inspect lib test files, package.json, the stdlib Makefile, and tools/harness.js. Compare the current tape-based test execution and TAP output with the proposed harness; completion means the migration scope, supported assertions, and CI validation are agreed and working across the affected tests.

Written by the indexing model from the issue text.

Assessment

Tech stack
javascript, node.js
Domain
build-system, testing-qa, tooling
Issue type
Refactor
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
20/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.