I have a Class that renders elements to a page, and I am trying to run a test that runs assertions after the drawing has completed. Here is my code:

import zora from "zora";
import {Rect} from "d3plus-shape";

export default zora()
  .test("Shape/Rect", assert => {

    new Rect()
      .data([{id: "test"}])
      .render(() => {

        assert.equal(document.getElementsByTagName("svg").length, 1);

      });

  });

When running using tape-run, zora never sees the assertion inside of the render callback. In raw tape, it will wait for assert.end() to be manually triggered. Are there any recommendations on how to do this with zora?

To reproduce, git clone https://github.com/binarykitchen/videomail-client/tree/feature/rollupjs && yarn install && yarn test. Produces this output:

└─( 2 ) ❱❱❱ yarn test                                                                       1 ⏎  +2635 22:37 ❰─┘
yarn test v0.27.5
$ rollup -c env/test/rollup.config.js | tape-run
🚨   (regenerator plugin) Line 523: Unexpected token =
node_modules/zora/dist/zora.es.js

internal/streams/legacy.js:59
      throw er; // Unhandled stream error in pipe.
      ^

Error: javascript required
    at Stream.<anonymous> (/home/michael-heuberger/code/videomail-client/node_modules/browser-run/index.js:35:34)
    at _end (/home/michael-heuberger/code/videomail-client/node_modules/through/index.js:65:9)
    at Stream.stream.end (/home/michael-heuberger/code/videomail-client/node_modules/through/index.js:74:5)
    at Stream.method [as end] (/home/michael-heuberger/code/videomail-client/node_modules/duplexer/index.js:47:39)
    at Stream.<anonymous> (/home/michael-heuberger/code/videomail-client/node_modules/throughout/index.js:7:25)
    at _end (/home/michael-heuberger/code/videomail-client/node_modules/through/index.js:65:9)
    at Stream.stream.end (/home/michael-heuberger/code/videomail-client/node_modules/through/index.js:74:5)
    at Stream.onend (internal/streams/legacy.js:44:10)
    at emitNone (events.js:110:20)
    at Stream.emit (events.js:207:7)
error Command failed with exit code 1.

Since it comes from node_modules/zora/dist/zora.es.js I guess I start reporting this here. Maybe you have any ideas/suggestions what this could be?

Just a senior dev saying thanks.
Zora is simple, lowdependency, minimal, and which runs in browser & CI.
A gem in a world which seems to be trapped into fiddling with operating-system-size testing frameworks.

At the moment, t.throws and t.doesNotThrow only accepts a function. It should also be able to accept a promise, like AVA.

I want to be able to test that Koa middleware throws a particular error:

(ctx, next) => {
  t.throws(next(), MyError)
}

It would be great if the function return value and promise resolved value would be returned. Here is an AVA example:

const promise = Promise.reject(new TypeError('🦄'));

test('rejects', async t => {
  const error = await t.throws(promise);
  t.is(error.message, '🦄');
})

Doing an

import { test } from "https://raw.githubusercontent.com/lorenzofox3/zora/master/src/index.ts"

gives this error:

Download https://raw.githubusercontent.com/lorenzofox3/zora/master/src/reporter
Download https://raw.githubusercontent.com/lorenzofox3/zora/master/src/interfaces
Download https://raw.githubusercontent.com/lorenzofox3/zora/master/src/harness
Download https://raw.githubusercontent.com/lorenzofox3/zora/master/src/assertion
error: Import 'https://raw.githubusercontent.com/lorenzofox3/zora/master/src/reporter' failed: 404 Not Found
    at https://raw.githubusercontent.com/lorenzofox3/zora/master/src/index.ts:2:0

Running the following test file should report a failure but does not:

// error.js
const {test} = require('zora')

test('error message with string', t => {
  t.throws(() => { throw new Error('message') }, 'another message')
})

Output:

$ node error.js 
TAP version 13
# error message with string
ok 1 - another message
1..1

# ok
# success: 1
# skipped: 0
# failure: 0

Hello,

I'm having following problem when having unhandled exceptions. I'm not sure if this is a problem of zora or from the reporter...

This is my test code

test('testgroup', t => {
    t.test('test', t => {
        throw "test"
    });
});

Result:

TAP version 13
# testgroup
# test
Bail out! Unhandled error.
(node:56299) UnhandledPromiseRejectionWarning: test
(Use `node --trace-warnings ...` to show where the warning was created)
(node:56299) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 1)
(node:56299) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

I would expect something like

TAP version 13
# testgroup
# test

Exception: "test"
Stacktrace: " /Users/david/dev/svelte-micro-router/public/test/src/router/Router.node.spec.js:15:11"
1..1

I also having this problem when i try to pipe the output to some other reporter. For example: I'm wondering why 0 failed tests?
It is not easy to see where the exception comes from.

▶ node public/test/src/router/Router.node.spec.js | npx tap-dot 
(node:56371) UnhandledPromiseRejectionWarning: test
(Use `node --trace-warnings ...` to show where the warning was created)
(node:56371) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 1)
(node:56371) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

  2 tests
  0 passed
  0 failed  

  Failed Tests:   There were 0 failures

Thank you for the beautiful test runner @lorenzofox3, it is very close to ideal. When do you think test.only and test.skip will be implemented?

Hey, this project looks pretty exciting! Seems like a spiritual successor to tape but written in TypeScript with zero dependencies, great performance, and built-in support for Promises. Yay! 🤩

I've been trying to write a test using jsdom-global, and for the moment just doing this:

import { test } from "zora";
import useDOM from "jsdom-global";

test("all that jazz", async (is) => {
  const cleanDOM = useDOM();

  document.body.appendChild(document.createElement("div"));

  is.equal(document.body.children.length, 1);

  cleanDOM();
});

This is rather fragile and not very elegant.

I didn't find anything in the README or your recipes list - is there a cleaner way to go about this?

I did try writing a helper function like this:

import useDOM from "jsdom-global";

export const withDOM = test => async () => {
  const cleanDOM = useDOM();

  const result = await test();

  cleanDOM();

  return result;
};

But first off, if I wrap my test-function in this, the IDE support and auto-completion is gone, since this particular project doesn't use TypeScript.

And even if I was willing to put up with that, for some reason the test just runs right through without any assertions.

I did get something like this working with tape and it's possible I'm being a doofus here and somehow creating a timing issue, not sure.

Do you know of a project with a test-suite using JS-DOM that I could look at?

I noticed a general problem with promises, which I also had with jest, but didn't seem to have with tape, which seems to somehow handle tests with deliberately "bad timing".

This type of issue happens for me constantly with both jest and zora - e.g. any time I forget an await statement in a test somewhere... The test runs green and unless you're manually counting assertions, there's a good chance you think you have a working test.

I don't know how tape gets around this - maybe I was just lucky, and the late assertions happen to emit TAP output that doesn't break the TAP stream. If that's the case, that's obviously pretty bad and not really a solution.

If we could somehow address this problem, that would be hugely helpful, I think?

Ideally, if assertion results are added to a closed stream, I'd like the program to simply exit with an error-message - so you'd know your test is bad and you can go fix it.

What do you think, is that possible?

I don't think the node process shuts down with promises and timeouts still pending? Not sure, but at least in the example I linked to above, that "late assertion" does get output.

It seems node changed the way modules are loaded. I am getting

> pta src/**/*.test.js

internal/modules/cjs/loader.js:958
      throw new ERR_REQUIRE_ESM(filename);
      ^

Error [ERR_REQUIRE_ESM]: Must use import to load ES Module: /var/storage/dev/projects/private/xstate.io/node_modules/zora/dist/bundle/index.js
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:958:13)
    at Module.load (internal/modules/cjs/loader.js:798:32)
    at Function.Module._load (internal/modules/cjs/loader.js:711:12)
    at Module.require (internal/modules/cjs/loader.js:838:19)
    at require (internal/modules/cjs/helpers.js:74:18)
    at Object.<anonymous> (/var/storage/dev/projects/private/xstate.io/node_modules/pta/src/cli.js:8:52)
    at Module._compile (internal/modules/cjs/loader.js:945:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:962:10)
    at Module.load (internal/modules/cjs/loader.js:798:32)
    at Function.Module._load (internal/modules/cjs/loader.js:711:12)
npm ERR! Test failed.  See above for more details.

on nodejs 12.11.0

In getAssertionLocation() in assertion.ts (v3.0.0-0), it looks for the fourth item in the stack, stack[3]:

const getAssertionLocation = (): string => {
    const err = new Error();
    const stack = (err.stack || '').split('\n');  
    return (stack[3] || '').trim().replace(/^at/i, '');
};

Sticking a console.log(stack), I get something like:

[ 'Error',
  '    at getAssertionLocation (/Users/jmakeig/Workspaces/object-describe/node_modules/zora/dist/bundle/index.js:192:17)',
  '    at Object.equal (/Users/jmakeig/Workspaces/object-describe/node_modules/zora/dist/bundle/index.js:201:27)',
  '    at Object.deepEqual (/Users/jmakeig/Workspaces/object-describe/node_modules/zora/dist/bundle/index.js:207:28)',
  '    at _80b‍.r.assert (/Users/jmakeig/Workspaces/object-describe/test/describe.test.sjs:151:10)',
  '    at t (/Users/jmakeig/Workspaces/object-describe/test/test.js:4:3)',
  '    at /Users/jmakeig/Workspaces/object-describe/node_modules/zora/dist/bundle/index.js:65:34',
  '    at tester (/Users/jmakeig/Workspaces/object-describe/node_modules/zora/dist/bundle/index.js:72:7)',
  '    at Object.test (/Users/jmakeig/Workspaces/object-describe/node_modules/zora/dist/bundle/index.js:323:25)',
  '    at test (/Users/jmakeig/Workspaces/object-describe/test/test.js:21:44)',
  '    at Object.<anonymous> (/Users/jmakeig/Workspaces/object-describe/test/describe.test.sjs:110:1)' ]

Line 5 (index 4) is really the interesting one, though. The extra entry in the stack is the result of deepEqual having a layer of indirection with aliasMethodHook('equal').

What is the intended behavior? Should getAssertionLocation() have some more smarts, such as the first non-zora message? In Node, Error.captureStackTrace() allows you to truncate the stack from the top to hide the implementation details above the userland code. Passing around the correct reference to assertion function gets tricky with all of the indirection, especially aliasMethodHook.

/** PROOF OF CONCEPT **/
function getAssertionLocation(below) {
    const err = new Error();
    if(Error.captureStackTrace) {
      Error.captureStackTrace(err, below);
      return err.stack.split('\n')[1].trim().replace(/^at/i, '');
    }
    const stack = (err.stack || '').split('\n');
    console.log(stack);
    return (stack[3] || '').trim().replace(/^at/i, ''); // This still will be wrong.
};

function genericAssertion(operator, compare/*(actual, expected)*/, description = `Should ${operator}`) {
  return function (actual, expected, description) {
    const pass = compare(actual, expected);
    const result = {
      pass,
      operator,
      actual,
      expected,
      description,
      at: comparison.pass ? undefined : getAssertionLocation(this[operator])
    };
    this.collect(result);
    return result;
  }
}

/* …snip… */

const AssertPrototype = {
    equal: genericAssertion('equal', fastDeepEqual),
    deepEqual: genericAssertion('deepEqual', fastDeepEqual),
    /* …snip… */
}

test(...) returns a promise and when I lint with ts-standard the error occurs that there is a dangling promise:

ts-standard: Typescript Standard Style! (https://github.com/standard/ts-standard)
   test.ts:4:1: Promises must be handled appropriately or explicitly marked as ignored with the `void` operator. (@typescript-eslint/no-floating-promises)

For now its a workaround to disable no-floating-promises for the test file but this will also skip the linting test for sections I don't use and adding one for each test seems tedious.

Is there a better way to avoid this issue?

I would like to ask for some advice how I can get the only mode working when using a test watch command. The command is watching all files for changes, if so the tests are executed. The command is running all the time while I'm implementing. When I'm using now the only method I get an exception during the execution and I have to restart the command. This is not a good workflow.

Have you any ideas how I can achieve this?
How is it behaving if I'm running in only mode without having only tests?
How can I set the only mode running inside a browser?

Thanks in advance!

I cloned the repo to poke at an issue, installed, and ran the tests, and they all fail.

It appears that the tests always return an empty string right now.

Tested on e1d8f5c (the latest commit in the master branch as I write this issue). macOS 10.14.

Here's the output of the final test as an example:

# sample output indented: skip.js
not ok 28 should be equal
  ---
    operator: equal
    expected: |-
      'TAP version 13\nok 1 - hey hey\nok 2 - hey hey bis\n# Subtest: hello world\n    ok 1 - should be truthy\n    # Subtest: blah\n        1..0\n    ok 2 - blah # SKIP\n    # Subtest: for some reason\n        1..0\n    ok 3 - for some reason # SKIP\n    1..3\nok 3 - hello world # {TIME}\n# Subtest: failing text\n    1..0\nok 4 - failing text # SKIP\n1..4\n\n# ok\n# success: 3\n# skipped: 3\n# failure: 0\n'
    actual: |-
      ''
    at: Socket.cp.stdout.on (/Users/josh/code/zora/test/samples/index.js:37:15)
    stack: |-
      Error: should be equal
          at Test.assert [as _assert] (/Users/josh/code/zora/node_modules/tape/lib/test.js:226:54)
          at Test.bound [as _assert] (/Users/josh/code/zora/node_modules/tape/lib/test.js:77:32)
          at Test.equal (/Users/josh/code/zora/node_modules/tape/lib/test.js:386:10)
          at Test.bound [as equal] (/Users/josh/code/zora/node_modules/tape/lib/test.js:77:32)
          at Socket.cp.stdout.on (/Users/josh/code/zora/test/samples/index.js:37:15)
          at Socket.emit (events.js:194:15)
          at endReadableNT (_stream_readable.js:1125:12)
          at process._tickCallback (internal/process/next_tick.js:63:19)
  ...

1..28
# tests 28
# pass  0
# fail  28

First off, thanks for making an awesome testing library! I just have a quick question:

In the Zora package.json there's a "module" property with a path to an ESM build that has named exports for every method, but when I import { test } from "zora"; in my test file (running Node 14.0.0), I get SyntaxError: The requested module 'zora' does not provide an export named 'test'. In my package.json I've specified "type": "module", but am using .js not .mjs.

I put together a minimal repro here. It seems that, for whatever reason, Node isn't loading the ESM build but the CommonJS build, because if I import zora from "zora"; it works and has the expected methods. To reproduce, you can npm run test or yarn run test in my repro.

Is this expected behavior? Do you know why it's happening?

this is really very nice and neat, any chance to have integration with wallabyjs :)

Hi really enjoy using this library. I had fun this past week trying it out in the browser, and as demonstrated in the readme and comparing it to ava and riteway. I did run into some challenges but finally settled on a config I think is best for my current projects.

I wanted to share this setup that's working for me with the zora community. I hope to test with puppeteer either tonight or tomorrow night.

{
  "scripts": {
    "test": "npx -n '-r esm' tape src/**/*.test.js",
    "test:coverage": "c8 npx -n '-r esm' tape src/**/*.test.js",
    "report": "c8 report"
  },
  "devDependencies": {
    "c8": "latest",  
    "esm": "latest",
    "tape": "latest",
    "zora": "latest"
  }
}

Additionally I also wrote a little helper function to help express my test output better. I think others might enjoy it if they concur Eric Elliot's views on testing

import { test, equal } from 'zora';

export { test };
export const assert = ({
  given,
  should = '',
  actual,
  expected,
}) => equal(
  actual, expected,
  `Given ${given}: should ${should}`,
);

I like how fast and light zora is, would it be possible for it to output proper exit codes? Or is that job of at the test-runner?

1. test case:

// wat.js
const test = require('zora')

test('what', t => {
    t.ok(false)
})

2. what I think should happen

$ node wat.js
$ echo $status
1

3. what is happening instead:

$ node wat.js
$ echo $status
0

When trying out zora in place of tape in one of my projects, I noticed that same doesn't mean the same thing — in zora, it's an alias to is, while in both tape and tap, it's an alias to deepEqual. It might be worth considering a breaking change for this to make it more consistent with other tap-producing testing tools (and so easier to switch).

Hey. Thanks for the cool and fast testing tool. Please tell me how can events be tested? In Jest, you can do it like this:

test("test result", (done) => {
    obj.addEventListener("finished", () => {
        done();
    });

    obj.processing();
});

You can read more about this here: https://jestjs.io/docs/en/asynchronous#callbacks. In the case of zora, I haven't found anything similar in the documentation.

Hi, I wonder if you considered this? I have thousands of integration tests, not that I need Zora, but were I to have started using it in the first place, it would be nice if it were a choice, instead of marking every test with await. I run them separated from my unit tests.

Super excited to see this honestly have spent the last month looking for a new testing framework and this looks amazing. Would you be open to if I committed a type definition set?

V3 is almost there ! in beta now, you can install it with npm install zora@next and start to review it.
The documentation is available in the readme of the branch v3.

Main changes are:

• target modern engines with use of for await and async generators
• is in typescript (#21 )
• still start automatically to report by default but it can also be controlled (#26 )
• there is more than a single default export (to avoid breaking changes in the future): the single export was introduced to be as close as possible as tape. It did not bring more traction in the project so I believe we can go with a more flexible approach
• Simplification of the assert library and more aliases for syntax sugar
• Reporters and assert library is friendlier for custom assertion (#25 )
• skip is implemented (#16 ) (only will come in a node specific test runner)

I am also working on small test runner specific to node but this can be aside

Any comment appreciated !

@styfle, @TehShrike @jmakeig

Currently the top level import does not return a valid Promise to use with async/await. Using nested tests seem to work fine.

const test = require('zora');
(async () => {
	console.log('1');
	await test('My long test', async t => {
		console.log('2');
		await t.test('My long subtest', async t => {
			console.log('3');
			await new Promise(res => setTimeout(res, 1000));
			console.log('4');
		});
		console.log('5');
	});
	console.log('6');
})();

Current output:

1
2
3
6
TAP version 13
# My long test
# My long subtest
4
5
1..0
# ok

Expected output (approximate, only order of numbers matters):

1
2
3
TAP version 13
# My long test
# My long subtest
4
5
6
1..0
# ok

From README.md:

You can for example play with this codepen

Fixed it in this fiddle: https://codepen.io/anon/pen/mXOwvQ

I just found this awesome modern library that’s smaller and simpler then tape.

I would love to change to this but the exit code being zero at all times is a blocker.

Can we add a little bit of feature detection ?

If typeof process !== undefined { process.exit(1) }

This lines doesn't works with typescript

// test/test.ts
import { test } from 'https://cdn.jsdelivr.net/npm/[email protected]/dist/bundle/module.js';
import { test } from '../node_modules/zora/dist/bundle/index.mjs';

I can only compile it with import { test } from 'zora' but after that node can't find ES6 module.

I’m struggling with how to get the at output in failing tests to use sourcemaps to display stacktraces in a transpiled environment. I can’t tell if this is a problem with my setup or Zora or just Node more generally.

I was hoping that running Node with source-map-support would magically address this, but I don’t see a difference running with or without it.

My tests and code are authored in TypeScript. I use rollup with the the rollup-plugin-typescript2 and rollup-plugin-multi-entry plugin to respectively transpile and concat all of my tests into a single ES2015 module output.

test.config.js

import multiEntry from 'rollup-plugin-multi-entry';
import nodeResolve from 'rollup-plugin-node-resolve';
import typescript from 'rollup-plugin-typescript2';

export default {
	input: 'src/**/*.test.ts',
	output: {
		format: 'esm',
		file: 'dist/tests.js',
		sourcemap: true
	},
	plugins: [
		multiEntry(),
		nodeResolve(),
		typescript({
			typescript: require('typescript')
		})
	]
};

tsconfig.json

{
	"compilerOptions": {
		"target": "es2015",
		"module": "es2015",
		"sourceMap": true,
		"noEmit": true,
		"strict": true,
		"moduleResolution": "node",
		"esModuleInterop": true,
		"inlineSourceMap": false
	}
}

Output

From the command line and the browser the tests run fine, other than the at value reporting the stacktrace of the transpiled/concatenated code.

npx rollup -c test.config.js && npx tsc && node -r esm -r source-map-support/register dist/tests.js

TAP version 13
# asdf
ok 1 - EQUAL
# another
not ok 2 - B
  ---
    actual: "b"
    expected: "c"
    operator: "equal"
    at: " Generator.next (<anonymous>)"
  ...
1..2

# not ok
# success: 1
# skipped: 0
# failure: 1

Note the at: " Generator.next (<anonymous>)". Running the same suite in the browser the output is at: "promiseReactionJob@[native code]".

The behavior is the exact same as without the -r source-map-support/register.

Whose responsibility is it to read the sourcemap to translate stacks in a Node environment? The browser console does this automatically to traverse resources, but the at value in the TAP output always seems to be calculated without any knowledge of the sourcemap.

Am I missing something in my build configuration? Any guidance would be much appreciated.

This library is such a breath of fresh air - really well done!

Currently I'm trying to create a integration/functional/semi-e2e test, using the "{sequence: true}" option.
I'd like for the test to "fail-fast", like in AVA's --fail-fast option (https://github.com/avajs/ava#cli), aka "Stop after first test failure".

However, it seems like you're currently on to something that will solve this: #7 (comment):

I am currently working on a version 2 which will have exactly the same API than other tap frameworks such node-tap or tape

Creating this issue so that version 2 will hopefully feature this 👍

I am currently working on a new version and I was thinking to remove BDD style to simplify code. Is anyone actually using it or not ?

My goal was to try fully ES6 tests that works in browser and puppeteer without transpilation.
As I understand for now it's only possible with Zora and node 10+ (or 12+).

Here my example:
https://github.com/munrocket/gl-bench/tree/master/test

Hey there! 👋

Very nice project! 🙏 I'm using it in my QuickJS experiment here: https://github.com/saghul/quv/blob/master/tests/t.js and I noticed that when I make a typo or something in a test, the output is just that the test bailed out, but I get no stack trace. Have I configured the harness wrong or something?

Cheers!

It would be nice if we could extend the assertions object to provide custom assertions.

I have prepared a minimal (probably) example: https://github.com/Alexey-Sch/zora-bug

Calling the function that is indicated by the link: https://github.com/Alexey-Sch/zora-bug/blob/master/tests/test.js#L37

It shouldn't interfere with the completion of the test, should it? I expect his call to go unnoticed. In reality, the test takes 30 seconds. If I wanted the method to take that long, I would use the done callback approach.

In Jest, execution would go to this line: https://github.com/Alexey-Sch/zora-bug/blob/master/tests/test.js#L39 and the test would end immediately.

I ran npm i zora today and got [email protected]. It doesn't have a default export, so import test from 'zora' failed, which is how I figured out something was up.

The readme doesn't seem to be updated in the v3 branch, so I'm guessing that v3 isn't ready for release yet? You might want to deprecate the v3 release on npm or something.

It seems like there's something weird going on when a test is imported to be used in a plan of plans.

index.js

import zora from 'zora'
import example from './example.js'

zora()
.test(example)
.run()

example.js

import zora from 'zora'
export default zora({sequence: true})

.test('is run before', async assert => {
    await new Promise(resolve => setTimeout(() => resolve(), 1000))

    console.log('before')
    assert.ok(true, 'before')
})

.test('is run after', assert => {
    console.log('after')
    assert.ok(true, 'after')
})

Now, 'after' is logged at once, followed by 'before' after a second, if you run node -r @std/esm index.js.

If I append .run() and remove export default from example.js, and run it directly - it works!
'before' pops up first, followed by 'after'.

Thought I'd let you know, even though the sequenced option is not yet documented :)

I was wondering if it's possible to have tests alternatively without generators. While still being able to return a promise, but without the *. buble es2015 transpiler doesn't support generator transpilation.

This would also be good for the new async functions that are coming out soon.

• nodejs commonjs
• nodejs es
• nodejs typescript
• browser vanilla (webcomponents
• browser react
• browser vuejs
• browser svelte

Creating this just in case it's not know - seems like all titles with emojis in them are broken!

Also, the "CLI" is a lie - for now :)

I'll gladly contribute to a few of the issues I created today if you'd like, @lorenzofox3.
Just let me know if there's a need for it. Asking just in case if you got something ready just around the corner!

While running Zora in React Native and to make sure the indent option is being propagated correctly to the runtime, I'm taking a snapshot of the tap output. The problem with this approach is that the snapshot becomes fragile as the number of milliseconds it takes to execute a subtest can easily change between runs.

Coming from node-tap which is way to slow for my taste I wonder if zora has support for beforeEach and afterEach patterns?

Hey!

This is kind of a follow up to our last exchange... I'm honored that you considered my suggestions for implementing only in Zora but, in the end, I am still not satisfied with the resulting workflow. I'm kind of an intensive user of watch + only with Mocha and I sorely miss not being able to do that in Zora. Even with my own suggested implementation, tending for the only chain turned out to be a drag...

So I implemented it for myself like I really wanted it. In order to be able to detect only automatically, I defer execution of top level tests (i.e. harness.test) until the call to report. I still want to be able to properly organize my tests, so I've also added a concept of "groups" (inspired from Mocha's describe) that enables nesting of top level tests. This allows me to use this pattern:

group('foo', () => {
  // the group callback is executed synchronously
  group('nested', () => {
    test('so I am still, in practice, a "top level" test', t => { ... })
    test.only('and so I can be auto-onlied!', ...)
  })
})

With that, I'm pretty satisfied. And here was born Zorax!

I'm in no way suggesting that you should implement anything like this in Zora. I love Zora being unopinionated and lightweight, so you can implement anything you like on top of it without it getting in the way.

Zorax is entirely built as a set of plugins, that people could use to compose their own custom harness if they want.

To be able to do that, I devised a minimal yet powerful plugin system over Zora. In essence, it automatizes the somewhat tedious and error prone task of wrapping test contexts and nested test contexts, to add extra functionalities (e.g. custom assertions) or override default behaviours.

I extracted this fundamental part as @zorax/plug, because I suspect more people might be interested in the extensibility for their own purposes than my mad scientist assemblage that is Zorax.

I wonder if such a plugin system shouldn't be part of Zora itself... For one thing, I suspect it could probably be implemented in a more efficient way, by adding to prototypes instead of adding to every created test context like I'm currently doing. Secondly, if Zora endorses the plugin system, then everyone's plugins will be compatible between them, instead of being, for example, Zorax-specific. Also, with Zora being so unopinionated, I feel that it would make sense for it to ship with a clear venue for extensibility, as an alternative to superfluous features.

Truly, I don't know... And I am totally satisfied with the current situation, since @zorax/plug is already available for me to use. But I wanted to offer the suggestion, and I would love to hear your thoughts about this.

Finally, I've seen the pta project you've started and was excited to try it, but found that integrating a watcher was still pretty rough (remember? watch + only is my kink...). Also, I must say I'm not a big fan of losing the "test is the program" paradigm to the test runner. So I stole you wonderful node reporter (was happy to find it as a standalone package, by the way -- thanks!), and went berserk with building a test runner more aligned with my own priorities. And here was born Zoar!

I mention it in case you're interested in adding a link to these projects in Zora's readme. No worries at all if that's not the case! But I cared to ask because otherwise, considering my general PR skills, they're probably bound to remain 1-user stuff forever ¯\_(ツ)_/¯

I really had a fun time hacking around Zora, and building tests for my hacks with it. Thanks again for your great job!

I have some clean up to do after all tests are finished. Currently I hijack console.log and watch for a regex. Is there a better way to do this?

If you throw an error from within the throws function, and use a RegExp instance for the expected value, the actual value is always just an object literal ({}).

test('throws', t => {
  t.throws(
      () => { JSON.parse('hello') },
      new RegExp('welp...')
    );
})

not ok 1 - should throw
  ---
  expected: "/welp.../"
  actual: {}
  at: " group.test.t (/path/to/run.mjs:55:7)"
  operator: "throws"
  ...

first, zora looks great, keep it going!

when I read at https://github.com/lorenzofox3/zora#as-part-of-ci-example-with-rollup I have a couple of constructive criticism questions:

-instead of importing each single test file inside test/index.js, can't we have a wildcard-based solution? so that we do not have update test/index.js each time we add a new test file?

-is there a solution to have the /test/dist part in memory instead so that it does not get written on disk which is imo not needed?

enuff for now :) tell me what you think of that?

It looks like v3 changes the module layout to use named exports, instead of the previous default export, such that the import statement now needs

import { test } from 'zora';

rather than

import test from 'zora';

as documented.

Or am I missing something?

Currently, zora just aliases same to is. In node-tap the same function is a much more sophisticated comparison that does deep object comparison and supports comparison of Buffers and other binary objects.

I tried to swap out node-tap for zora in order to get browser support and immediately hit this problem.

Specifically, I am trying to test that my asynchronous code throws. (In other words, that a promise rejects...) So, I would like the following to work:

t.throws(async () => {
  await myAsyncCode();
});

This does not currently work because we don't await the function call at

The same is true for doesNotThrow.

If this would break code I would like to propose new assertions resolves and rejects that would accept promises and await them and assert that they resolve or reject respectively.