power-assert-js/empower

Power Assert feature enhancer for assert function/object

empower's Issues

Alternate "slim" version of empower.

@twada

Poking through the code, I think there is room for a "slim" version of empower.

If my understanding is correct, then the following:

saveContextOnRethrow: true,
modifyMessageOnRethrow: false

Does not require a formatter at all. It just attaches the context and re-throws a copy.

In the "slim" version I am picturing, it would only take a patterns argument.

Also, instead of re-throwing an error (which messes with the existing stack trace needlessly). You could just use serialize-error attach the context, and throw.

We would format and print the message on the main thread using powerAssertContext.

Is what I am saying making sense?

Possible async problem

Now that we support async functions, is the fact that this is in a closure going to be a problem?

I am near certain the answer is yes!

Look at this code:

test('a', t => {
  t.is(await promiseA1(), await promiseA2());
});

test('b', t => {
  t.is(await promiseB1(), await promiseB2());
});

Now, assume both following sequence of events:

1. test a starts
2. test a halts as it awaits the resolution of promiseA1()
3. test b starts
4. test b halts as it awaits the resolution of promiseB1()
5. promiseA1() resolves, and test a resumes.
6. test a halts as it awaits the resolution of promiseA2()
7. promiseB1() resolves, and test b resumes.
8. test b halts as it awaits the resolution of promiseB2()
9. promiseB2() resolves, and test b resumes.
10. test b ends
11. promiseA2() resolves, and test a resumes.

It seems like events is going to be corrupted by step 12.

I think AVA is going to need to create a new enhanced assert object for each run.

@twada - thoughts?

process.stdout.getColorDepth is not a function

Getting a lot of these errors when using power-assert (without babel plugin) in ava tests:

Uncaught exception in test/normalizers/normalizeScraperVenueResults.js

/Users/gajus/Documents/dev/applaudience/cinema-data-scraper/node_modules/empower/index.js:33

TypeError: process.stdout.getColorDepth is not a function

isStackUnchanged (node_modules/empower/index.js:33:18)
empower (node_modules/empower/index.js:40:7)
applyEmpower (node_modules/power-assert/index.js:41:16)
customize (node_modules/power-assert/index.js:47:25)
Object.<anonymous> (node_modules/power-assert/index.js:64:21)
Module._compile (node_modules/pirates/lib/index.js:91:24)

✖ test/normalizers/normalizeScraperVenueResults.js exited with a non-zero exit code: 1

record / playback of all assertions (not just failed ones).

Helpful for assertion libraries that do not throw when they reach the first failed assertion, but try every assertion possible (like tap and ava).

assert._reset(); //clear log of assertions

assert.ok(two + two === 4);
assert.ok(three + two === 5);
assert.ok(four + two === 6);

assert._callStack();
// => [
//      {content: 'assert.ok(two + two === 4);', args:[...]},
//      {content: 'assert.ok(three + two === 5);', args:[...]},
//      {content: 'assert.ok(four + two === 6);', args:[...]}
//    ]

`_expr` and `_capt` should not be enumerable

Currently, _expr and _capt methods are simply added but these methods would be better not to be enumerable.

See: Less API using power-assert by uiureo · Pull Request #46 · sindresorhus/ava

Require Performance

Start time: (2015-11-24 06:15:01 UTC) [treshold=1%,sorted]
# [order]  module                        time  %
   1 [43]  empower (node...er/index.js)  37ms  ▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇ 84%
   2 [36]  ./lib/decorat...ecorator.js)  33ms  ▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇ 75%
   3 [28]  escallmatch (...ch/index.js)  31ms  ▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇ 70%
   4  [9]  esprima (node.../esprima.js)  19ms  ▇▇▇▇▇▇▇▇▇▇▇▇▇ 43%
   5 [19]  espurify (nod...fy/index.js)   5ms  ▇▇▇▇ 11%
   6  [7]  chalk (node_m...lk/index.js)   4ms  ▇▇▇ 9%
   7 [42]  define-proper...es/index.js)   2ms  ▇▇ 5%
   8 [11]  estraverse (n...traverse.js)   2ms  ▇▇ 5%
   9 [35]  ./decorate (n...decorate.js)   2ms  ▇▇ 5%
  10 [16]  ./lib/create-...hitelist.js)   2ms  ▇▇ 5%
  11 [27]  deep-equal (n...al/index.js)   2ms  ▇▇ 5%
  12  [4]  ansi-styles (...i-styles.js)   1ms  ▇ 2%
  13 [37]  ./lib/captura...pturable.js)   1ms  ▇ 2%
  14  [5]  strip-ansi (n...si/index.js)   1ms  ▇ 2%
  15 [14]  object-keys (...ys/index.js)   1ms  ▇ 2%
  16  [6]  has-color (no...or/index.js)   1ms  ▇ 2%
  17  [0]  text-table (n...le/index.js)   1ms  ▇ 2%
  18 [17]  isarray (node...ay/index.js)   1ms  ▇ 2%
  19 [18]  ./lib/clone-a...lone-ast.js)   1ms  ▇ 2%
  20  [8]  ./lib/default...-options.js)   1ms  ▇ 2%
  21 [33]  array-map (array-map)          1ms  ▇ 2%
  22 [21]  array-map (no...ap/index.js)   1ms  ▇ 2%
  23  [1]  date-time (no...me/index.js)   1ms  ▇ 2%
  24 [23]  array-reduce...ce/index.js)    1ms  ▇ 2%
  25  [2]  parse-ms (nod...ms/index.js)   1ms  ▇ 2%
  26  [3]  pretty-ms (no...ms/index.js)   1ms  ▇ 2%
  27 [26]  ./lib/is_argu...rguments.js)   1ms  ▇ 2%
Total require(): 44
Total time: 44ms

Looks like escallmatch is the big offender here. Moving to call-signature should help. If that ends up being unworkable, at least have escallmatch use acorn, so we only require one parser library.