Feature Request: Prebound assertion functions

[ryardley]

It would be useful and functional to be able to destructure test functions such as pass, fail, deepEqual, it etc. from the test object argument passed into the test function. Currently they are not bound to the test context but could probably be provided pre-bound.

test(({ deepEqual }) => {
    deepEqual([1, 2], [1, 2]);
});

[sindresorhus]

I don't really see how that is any more readable than:

test(t => {
    t.deepEqual([1, 2], [1, 2]);
});

It actually get's very verbose when you use multiple assertions, which is common:

test(({ deepEqual, is, throws }) => {
    deepEqual([1, 2], [1, 2]);
    is(1, 1);
    throws(() => foo());
});

Let's see what the other team members think.

Maybe you can elaborate on why you want it this way.

[ryardley]

The Javascript community is moving towards a more functional style and being able to use methods functionally without depending on an object context is becoming quite common.

I can certainly see this as a low priority change but coming to the API for the first time I think it was something I expected to be able to do but was surprised I could not and I figure it would probably not be a huge change.

Honestly probably the main reason you want to do this is that it works with tape and would remove friction moving to ava:

// tape
test('timing test', ({plan, equal}) => {
    plan(2);
    equal(typeof Date.now, 'function');
    const start = Date.now();

    setTimeout(function () {
      equal(Date.now() - start, 100);
    }, 100);
});

[novemberborn]

The Javascript community is moving towards a more functional style and being able to use methods functionally without depending on an object context is becoming quite common.

Could you give an example of a test you would write with a functional style? I can think of this scenario:

someArray.forEach(t.true)

But that only seems useful for assertions that have no expectations, e.g. not t.deepEqual(). It also wouldn't work, since the array index will be passed as the assertion message, which is (will soon be) an error. You'd have to do:

someArray.forEach(value => t.true(value)

At which point I don't see the usefulness in binding the assertions to the t object.

Currently we also need the t. for power-assert.

[ryardley]

You can get around that by using lodash's spread function or ramda's apply. A use case might be some table testing like so:

// eg. using ramda
test('test all the things', ({ deepEquals }) => {
  thingsToTest
    .map(({ input, expected }) => [ myfunc(input), expected ])
    .map(apply(deepEquals));
});

However if there are restrictions in place by power-assert then that prevents this being something quick to implement so perhaps that is reason to shelve the idea as low priority.

[sindresorhus]

It's very easy to implement. We already bind t.end(). The problem is that if we support it, people will expect it to be documented, and I'm not sure it's a pattern we want to recommend.

[novemberborn]

.map(apply(deepEquals)); can also be written as .map(args => t.deepEqual(...args);. I'd recommend that over helper methods, actually.

[jamestalmage]

It actually is not that easy to implement because of the way power-assert recognizes patterns. See power-assert-js/babel-plugin-espower#18

[novemberborn]

With the recent assertion refactor I think we can make it so the assertion knows whether it's bound or not, so unbound enhanced assertions know that they're not wrapped by power-assert.

That said I'm somewhat concerned about the performance impact, and not convinced about the value-add.