-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Comments
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. |
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);
}); |
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 someArray.forEach(value => t.true(value) At which point I don't see the usefulness in binding the assertions to the Currently we also need the |
You can get around that by using lodash's // 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 |
It's very easy to implement. We already bind |
|
It actually is not that easy to implement because of the way |
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 That said I'm somewhat concerned about the performance impact, and not convinced about the value-add. |
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.The text was updated successfully, but these errors were encountered: