Suffix location matching (Match test locations where test name and code structure differ) #1922
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
WHAT
More tests have locations
Improve matching of test explorer items to code locations.
Specifically, detect tests that are logically grouped by a testList, but not directly located under that same testList in the code.
Example
Before, these tests didn't have features based on code location
After
Mislocated tests don't pollute the explorer
Also prevent mislocated tests from showing in the test explorer.
The production version already prevented these on initial discovery, but they would still show up if the tests were renamed.
Now the incorrect test items shouldn't show at all.
For example, the Not Directly in Parent test should be nested under
Composed test lists?
andComposed test lists - 2
and is not a root level test.Before
After
HOW
If an explorer test can't be located in code, check if any of the code test ids are a suffix of the explorer test id.
Known Issues
+
or.
.Alternative Approaches
I hoped to solve this within the FSAC
testDetected
endpoint.This would have made it simple to support live explorer updates, and the code analysis results would have been more aligned with the logical structure of the tests.
The basic idea was to try resolving any referenced values within an expecto testList.
However, it doesn't look like this can be done with the untyped expression used for detecting tests.
Using the typed expressions seemed like a heavy update that could cause performance issues with how frequently this analysis is run.
I didn't measure the performance of using the typed expressions though. It may still be viable.
I also may have missed options for resolving symbols in the untyped AST.
Performance
I tested this on large numbers of tests in several repos, since it runs every time the code updates.
I didn't observe any slowdowns, but I'm 100% confident this can't cause performance issues.