bcoin-org / bmocha Goto Github PK

Many of the b* repos implement things that already exist and are actively developed by other teams, while there are things like SPV or multisig that are not 100% covered in the bcoin implementation. I hope I'm not being too nosy, but I would like to know if there is a reason why a lot of energy is spent on what seemingly is a duplication of effort, while there are unresolved issues with the core bcoin library.

Even though a test has failed and process.exit is run with 1, CircleCI is still exiting with a code of 0. It seems like the error code is getting swallowed somewhere. Tried running with mocha and it fails as expected.

OSX

$ npm --version
6.9.0

$ node --version
v11.11.0

I'd like to test browser functionality of bcoin and hsd. After install browserify and bpkg globally, running this command for bcoin#master (which doesn't yet have a 2.x.x version of bmocha) throws an error.

$ ./node_modules/.bin/bmocha -H --reporter spec test/*.js
Error: Browserify not installed!
...

According to the docs, it should work on a globally installed browserify.

After updating bmocha on bcoin, digging into [email protected] to determine
why this is happening, I found the list of node_modules paths are generated here:

Logging those paths, none of them include the directory in which npm installed browserify and bpkg.

$ which bpkg
/usr/local/bin/bpkg

$ which browserify
/usr/local/bin/browserify

Looking at where npm installs things globally:

$ npm list -g | head -n 1
/usr/local/lib

I can't find any changelogs that refer to changing the location of the global installs, but did find this: https://docs.npmjs.com/files/folders

The prefix config defaults to the location where node is installed. On most systems, this is /usr/local. On Windows, it’s %AppData%\npm. On Unix systems, it’s one level up, since node is typically installed at {prefix}/bin/node rather than {prefix}/node.exe.
When the global flag is set, npm installs things into this prefix. When it is not set, it uses the root of the current package, or the current working directory if not in a package already.

This corresponds to my local install of Node.js

$ which node
/usr/local/bin/node

This means that the docs here are not fully correct for OSX at least:
https://github.com/bcoin-org/bmocha#headless-chrome--browser-support

OSX

$ node --version
v11.11.0

$ ./node_modules/.bin/bmocha --version
2.1.0

For debugging with Chrome Devtools, I think that it may be more useful in practice to replace debug and inspect with debug-brk and inspect-brk so that when running bmocha -d, the debugger pauses before running through all the tests. It seems to ignore my debugger statements when using inspect (the spawned process receives --inspect), but I can successfully open up the Chrome debugger and it stops at my debugger statements if I replace inspect with inspect-brk so that --inspect-brk is passed to the spawned process.

Simply making that change at the lines above breaks the normal debug argument. The Chrome debugger is a really nice tool but using the CLI debugger works well too

Versions
bmocha v1.0.1

Expected

Given this directory and file structure:

./test/util/util.js
./test/bar/baz-test.js
./test/bar/qux-test.js
./test/foo-test.js

For this command:

$ bmocha --recursive "./test/**/*-test.js"`

To run these files:

./test/bar/baz-test.js
./test/bar/qux-test.js
./test/foo-test.js

Actual

File not found: test/**/*-test.js

Alternatives

It could be possible to run:

$ bmocha --recursive ./test/

However then all of the files are loaded, including the util files.

Another option:

$ bmocha --recursive ./test/*-test.js

Will only match, or recurse, anything that matches the initial *-test.js file list, which won't be the bar directory, and thus will only run ./test/foo-test.js

Proposal

Option A)

Introduce two new arguments --directory and --files, example usage:

$ bmocha --recursive --directory="./test/" --files="*-test.js"

Files could use a regexp for matching, or more shorthand * syntax.

Option B)

Use the globstar pattern matching, as would match mocha behavior more similarly:

$ bmocha --recursive "./test/**/*-test.js"`

I noticed there's small difference with browserify vs bpkg backends.
bpkg correctly translate main using browser mappings where browserify
does not translate it using browser mappings.

command: ./node_modules/.bin/bmocha --open -m "$BMOCHA_CHROME" test/*-test.js

e.g.
package.json of the library being used.

{
  "name": "test",
  "main": "./lib/test.js",
  "browser": {
    "./lib/test": "./lib/test-browser.js"
  }
}

This will fail(wont resolve to browser) with browserify backend:

const lib = require('test');

but following will work on both:

const lib = require('test/lib/test');

bmocha has a feature mocha does not: detecting multiple resolves.

I understand its use in the serial case, like the bmocha test:

But how can a series of tests be written where the same promise-resolving-event needs to be awaited?

const EventEmitter = require('events');
const emitter = new EventEmitter();

describe('Multiple resolves', function() {
  it('should wait for 1st event', async() => {
    const waiter = new Promise((resolve) => {
      emitter.on('event', () => {
        resolve();
      });
    });

    emitter.emit('event');

    await waiter;
  });

  it('should wait for 2nd event', async() => {
    const waiter = new Promise((resolve) => {
      emitter.on('event', () => {
        resolve();
      });
    });

    emitter.emit('event');

    await waiter;
  });
});

This test fails with Uncaught Error: Multiple resolves detected for undefined.
The result is the same if I try to destroy the first promise with waiter = null