Allow destructuring of assertions

[kl0tl]

Bound methods would allow to destructure assertions while waiting for something like tc39/proposal-bind-operator#5 to happen.

import test from 'ava';

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

[sindresorhus]

Why would you use that? It's more verbose than t.same().

[kl0tl]

For a single assertion yes, but it would be a nicer when multiple assertions are used multiple times in the same test.

[kl0tl]

And while this test is trivial I like how it makes immediately clear what assertions I'm using.

[sindresorhus]

We'll consider it, but this honestly feels like just using a new language feature for the sake of it, rather than actually being beneficial. It also IMHO makes tests look more noisy and inconsistent.

And while this test is trivial I like how it makes immediately clear what assertions I'm using.

I don't see any benefit of knowing that up front.

[kl0tl]

I may have been too used to it. Anyway, it means losing the power-assert output while #550 is pending.

[briandipalma]

id-length warnings in ESLint are triggered by t so it would be handy if we could use destructuring as a way to silence those.

[jamestalmage]

id-length warnings in ESLint are triggered by t so it would be handy if we could use destructuring as a way to silence those.

Add t to the exceptions property: http://eslint.org/docs/rules/id-length#exceptions

[jamestalmage]

I think this should just be closed. Allowing this would require significant effort for power-assert, our codemods, and linter. All to allow something of dubious value.

[briandipalma]

Any chance we could import the assertion functions from ava so there is no need for the t reference?

[jamestalmage]

Any chance we could import the assertion functions from ava so there is no need for the t reference?

No, the t reference is specific to that particular test. We keep track of the assertion count, so you can use t.plan

[novemberborn]

Destructuring t for each test you write seems cumbersome.

From the id-length description:

Very short identifier names like e, x, _t or very long ones like hashGeneratorResultOutputContainerObject can make code harder to read and potentially less maintainable.

I don't think that applies to AVA tests.

---

Closing this because the effort required isn't worthwhile.