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
Analyze source & test dependencies to figure out which tests to run (first) #1986
Comments
I have come up with 2 ideas worthy to have a try:
Don't blame me if not working ;) |
Seems to be a feature request, what do you think @novemberborn? |
@momocow Thanks for the thoughts, I don't think either of those really work.
@havenchyk I'm new to |
Doesn't seem too complicated. If given a list of test files and a list of staged files, all that needs to be done is determine which if any test files import from the staged file list (passed as command line arguments). My vote would be to keep/use the |
Yea AVA doesn't do this. Watch mode merely notes which source files are depended on my test files, and uses that to re-run specific test files. It should be possible to do this outside of AVA by analyzing the dependency tree to select the test files to run. It'd be neat if AVA could do the same to prioritize which tests to run. Would be great if somebody could spec out how this should work and we can take it from there. |
Until there is a robust system to analyze the actual test and source files to figure out what to run, you could get 90% of the way there by using It's not perfect, because |
I'm new to this repository, so my solution is a little rough haha, but after reading what @sholladay said, I figured it would be simple to implement. I got it working by adding a flag to the cli prioritize: {
type: 'string',
default: []
} Which I later use in let files = '';
if (cli.flags.prioritize.length > 0) {
console.log(`You're prioritizing ${cli.flags.prioritize}`);
files = cli.flags.prioritize.split(' ').forEach(file => {
let temp = file;
file = file.replace('.js', '.test.js');
console.log(`${temp} is now ${file}`);
});
} else {
files = cli.input.length > 0 ? cli.input : arrify(conf.files);
} Of course there are some issues here, we would probably want to pull the desired test suffix out of the ava config file for one. |
@AgentBurgundy you can already pass specific file paths to AVA, so you could do this without changing AVA itself. |
@IssueHunt has funded $80.00 to this issue.
|
FWIW, AVA now treats the file paths you provide as a filter over the tests it would execute normally. Which means you can pass staged files. AVA itself now supports just JavaScript, with Babel and TypeScript support implemented in separate packages. Parsing the source tree to build a priority list is possible but difficult. Still, it'd be cool to have and doesn't change our other internals. |
This is complicated a bit by my use case, which is a yarn workspace monorepo with dozens of modules. Tests live in the It makes me think that what we need is a 3rd party module that does the above (if it doesn't already exist) It also makes me think that what jest was doing was magic, because it did what I just described pretty well. (https://jestjs.io/docs/cli#--lastcommit) |
@NathanielHill, it doesn’t solve the overall problem, but this step can be achieved via @rrichardson, FWIW, this is the crux of Jest’s solution, as explained here. |
Just trying out AVA instead of Jest in a new monorepo project. I am configuring testing to be run as a pre-commit hook using
husky
andlint-staged
.I've run into a problem getting the appropriate tests run by
ava
during a commit. Previously, I would uselint-staged
which would pass the changed files as arguments tojest
and using the--findRelatedTests
flag, jest would run only the tests that covered those files.Trying to do something similar with
ava
has left me at a dead-end. If I try to uselint-staged
to runava
, it passes a list of changed files andava
tries to run them as tests which fails. The alternative is simply to run the entire test suite, which will become inefficient as the project grows.Any thing I'm missing, or thoughts on how to run appropriate
ava
tests as part of a pre-commit process?The text was updated successfully, but these errors were encountered: