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

Use testPathPattern as a filter on top of findRelatedTests #8311

Closed
wants to merge 22 commits into from
Closed

Use testPathPattern as a filter on top of findRelatedTests #8311

wants to merge 22 commits into from

Conversation

mackness
Copy link
Contributor

@mackness mackness commented Apr 11, 2019

Summary

Based on this issue #5129 --findRelatedTests is overriding --testPathPattern. The goal of this PR is to apply --testPathPattern as a filter on top of results returned by --findRelatedTests.

Test plan

Planning on adding tests for the _getTestPaths method in SearchSource.ts

@jeysal
Copy link
Contributor

jeysal commented Apr 11, 2019

@mackness Thanks for taking time to tackle this, let us know if you get stuck anywhere :)

if (globalConfig.testPathPattern !== null) {
return {
tests: relatedTests.tests.filter(test =>
new RegExp(globalConfig.testPathPattern).test(test.path),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd probably try to reuse the logic in _filterTestPathsWithStats on the related tests, hopefully this helps as a hint

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is very helpful, I was wondering why was not seeing the stats output when 0 tests were matched. Making the update now!

Mack Solomon added 3 commits April 11, 2019 18:12
We only want to _filterTestPathsWithStats if testPathPattern was
explicitly passed as an argument. The issue is that it's not possible to
simply null check globalConfig.testPathPattern to determine if it was
explicity passed becase that field gets populated with values passed to
findRelatedTests also. This approach compares the values in
globalConfig.testPathPattern to the values in globalConfig.nonFlagArgs
and if it is a 1 to 1 match it is assumed that testPathPattern was not
explicity passed as an argument.
@codecov-io
Copy link

Codecov Report

Merging #8311 into master will decrease coverage by 0.02%.
The diff coverage is 0%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #8311      +/-   ##
==========================================
- Coverage   62.17%   62.15%   -0.03%     
==========================================
  Files         266      266              
  Lines       10683    10687       +4     
  Branches     2597     2598       +1     
==========================================
  Hits         6642     6642              
- Misses       3452     3456       +4     
  Partials      589      589
Impacted Files Coverage Δ
packages/jest-core/src/SearchSource.ts 55.91% <0%> (-2.52%) ⬇️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 034ab25...d83b4c6. Read the comment docs.

@jeysal
Copy link
Contributor

jeysal commented Apr 13, 2019

@mackness I just took a look at your updates - it appears that the root cause of what you worked around with d83b4c6 is that we are using all the non-option arguments to find related tests, so the non-option arguments become both parts of testPathPattern and findRelatedTest roots. I think the way forward is to let yargs parse findRelatedTests as an array instead of just a boolean flag (which seems like the right thing to do anyway), see https://github.com/facebook/jest/blob/538cef4c4ed15686a40380550041c3993a8e26ce/packages/jest-cli/src/cli/args.ts#L268
This will require adapting the config typings and then you should be able to use the config properties testPathPattern and findRelatedTests separately :)
cc @SimenB in case I'm missing something

@mackness
Copy link
Contributor Author

@jeysal That seems like a much better approach, my workaround definitely did not feel right. I'll let you know if I runt into any issues with the implementation, thanks for the suggestion!

@mackness
Copy link
Contributor Author

Hi @jeysal I am letting yargs parse findRelatedTests as a string array and a few issues came up:

  1. A couple hard to solve typing issues. (1, 2)

  2. For some reason when findRelatedTests is not explicitly passed the option is parsed as [undefined]. Maybe yargs parses it this way for some reason? workaround

  3. Lots of failing snapshot tests, not sure which snapshots I can simply update and which ones are failing for legitimate reasons.

I will keep trying to track down the root cause of 1 and 2 but a little bit of direction with 3 would be greatly appreciated, thanks!

@jeysal
Copy link
Contributor

jeysal commented Apr 18, 2019

@mackness After a quick glance, most of the snapshots seem like legimitate failures that need fixing to me.
For e.g. this kind of stuff
image
see https://github.com/facebook/jest/blob/3e05c06aac5778c4f3365b3c673a7ce68b6a392d/packages/jest-reporters/src/summary_reporter.ts#L192

There's also coverage related failures. Coverage has special interaction with stuff like findRelatedTests and onlyChanged. Looking at the places touched by #5601 and #6736 would probably help. In general, grepping for config.findRelatedTests to find locations impacted by the config change is a good idea I think :)

@mackness
Copy link
Contributor Author

@jeysal Ok awesome I'll work on making the tests pass and adding a couple tests of my own, thanks!

findRelatedTests used to be a boolean field. It has been updated to be Array<string>. We will check the length of the array to determine if findRelatedTests is falsy or truthy since 0 will evaluate to false and aything greater than 0 will evaluate to true.
@mackness
Copy link
Contributor Author

yep, I'll make the change :)

@JoshRosenstein JoshRosenstein mentioned this pull request May 7, 2019
for some reason this lint command works locally but fails in CI

eslint . --cache --report-unused-disable-directives --ext js,jsx,ts,tsx,md --format junit -o reports/junit/js-lint-results.xml
@jeysal
Copy link
Contributor

jeysal commented Jun 3, 2019

@mackness Let me know when you think this is ready for review again or if you run into any other problems :)

@mackness
Copy link
Contributor Author

mackness commented Jun 3, 2019

@jeysal Thanks! I am planning on adding a few more unit tests and there are a couple typing issues I need to take care of then It will be ready for another review.

One question this fails in CI but it does not fail locally. Also it does not seem related to code I changed. Do you know what might be causing eslint to complain about no-unresolved?

Maybe because fsevents is an optional dependency in jest-haste-map?

https://github.com/facebook/jest/blob/master/packages/jest-haste-map/package.json#L35

@jeysal
Copy link
Contributor

jeysal commented Jun 4, 2019

Yeah I get those too, idk why - maybe @SimenB knows?
I usually just ignore those and pretend that lint passed if it's just those three errors :P

@SimenB
Copy link
Member

SimenB commented Jun 4, 2019

I think this is due to fsevents only being available on mac, so if you're not on mac (like CI is) it errors

@github-actions
Copy link

github-actions bot commented Sep 8, 2022

This PR is stale because it has been open 1 year with no activity. Remove stale label or comment or this will be closed in 30 days.

@github-actions github-actions bot added the Stale label Sep 8, 2022
@github-actions
Copy link

github-actions bot commented Oct 8, 2022

This PR was closed because it has been stalled for 30 days with no activity. Please open a new PR if the issue is still relevant, linking to this one.

@github-actions github-actions bot closed this Oct 8, 2022
@github-actions
Copy link

github-actions bot commented Nov 8, 2022

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Please note this issue tracker is not a help forum. We recommend using StackOverflow or our discord channel for questions.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Nov 8, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants