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

Handle destructured import of a test modifier #121

Closed
sindresorhus opened this issue Jun 22, 2016 · 7 comments · Fixed by #232
Closed

Handle destructured import of a test modifier #121

sindresorhus opened this issue Jun 22, 2016 · 7 comments · Fixed by #232
Labels
enhancement 🎁 Rewarded on Issuehunt This issue has been rewarded on Issuehunt help wanted

Comments

@sindresorhus
Copy link
Member

sindresorhus commented Jun 22, 2016

Issuehunt badges

From sindresorhus/conf#2 (comment)

I think we should handle the following cases:

import {serial as test} from 'ava';
import {serial} from 'ava';

It's a useful pattern to make a test file with only serial tests.


IssueHunt Summary

alexzherdev alexzherdev has been rewarded.

Backers (Total: $80.00)

Submitted pull Requests


Tips


IssueHunt has been backed by the following sponsors. Become a sponsor

@jfmengels
Copy link
Contributor

Are there any other methods that are aliases to test.XXX?
If I do

import {cb as test} from 'ava';
test(...);

is that equivalent to

import test from 'ava';
test.cb(...);

or is serial a special one?

@jamestalmage
Copy link
Contributor

All methods can be destructured and will work as expected, all the following are valid:

{cb as test}
{serial as test}
{cb as test}

You could even try something like this for a mocha-like interface:

import {beforeEach, afterEach, cb as it} from 'ava';

beforeEach(t => {...});

it('does things', t => {...});

Most of our rules should try and support all of those. We can update the use-test rule to warn against any particular patterns we don't like.

@jfmengels
Copy link
Contributor

An idea for an other time, but maybe we could have an option in use-test that forbids destructuring of test, if users want to stick to the explicit test.

@jfmengels
Copy link
Contributor

jfmengels commented Jun 23, 2016

By the way, this looks a lot like what I did in eslint-plugin-lodash-fp. Starting to think we could maybe make a separate "enhancer" for this using enhance-visitor. Just to do the import logic understanding as in the lodash-fp link, and then we'll have to update the rules to use that.

@jamestalmage
Copy link
Contributor

Much of the static-analysis work is already complete in babel-plugin-ava-test-data, so it should just be a matter of porting for the eslint API.

@IssueHuntBot
Copy link

@IssueHunt has funded $80.00 to this issue.


@issuehunt-oss issuehunt-oss bot added the 💵 Funded on Issuehunt This issue has been funded on Issuehunt label May 10, 2019
@issuehunt-oss issuehunt-oss bot added 🎁 Rewarded on Issuehunt This issue has been rewarded on Issuehunt and removed 💵 Funded on Issuehunt This issue has been funded on Issuehunt labels Sep 16, 2019
@issuehunt-oss
Copy link

issuehunt-oss bot commented Sep 16, 2019

@sindresorhus has rewarded $72.00 to @alexzherdev. See it on IssueHunt

  • 💰 Total deposit: $80.00
  • 🎉 Repository reward(0%): $0.00
  • 🔧 Service fee(10%): $8.00

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement 🎁 Rewarded on Issuehunt This issue has been rewarded on Issuehunt help wanted
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants