Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Request: Prebound assertion functions #1255

Closed
ryardley opened this issue Feb 11, 2017 · 8 comments
Closed

Feature Request: Prebound assertion functions #1255

ryardley opened this issue Feb 11, 2017 · 8 comments

Comments

@ryardley
Copy link

ryardley commented Feb 11, 2017

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]);
});
@ryardley ryardley changed the title Feature Request: Feature Request: Prebound assertion functions Feb 11, 2017
@sindresorhus
Copy link
Member

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
Copy link
Author

ryardley commented Feb 11, 2017

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
Copy link
Member

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
Copy link
Author

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
Copy link
Member

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
Copy link
Member

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

@jamestalmage
Copy link
Contributor

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
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants