-
-
Notifications
You must be signed in to change notification settings - Fork 88
Add integration test setup; check for legacy/new scope duplicates #1428
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
Add integration test setup; check for legacy/new scope duplicates #1428
Conversation
f083bea
to
aab6502
Compare
8bc2544
to
b0e6e8e
Compare
@@ -68,5 +69,7 @@ export function createCursorlessEngine( | |||
hatTokenMap, | |||
snippets, | |||
injectIde, | |||
runIntegrationTests: () => | |||
runIntegrationTests(treeSitter, languageDefinitions), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we instead expose treeSitter
and languageDefinitions
, then we could avoid runIntegrationTests
ending up in the prod bundle, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No I don't think that would help. The issue is that the test needs to be defined inside cursorless engine; see PR description for more detail. Also notice that treeSitter actually comes from the caller, so exposing it wouldn't actually do anything
We'd need to expose everything imported in the file that defines the integration tests
But maybe I've misunderstood your proposal?
b0e6e8e
to
dfe7e46
Compare
c0aeedf
to
631aa40
Compare
7b8c289
to
a5b756c
Compare
a5b756c
to
c4191dd
Compare
…egacynew-scope-duplicates
This PR adds a test to ensure that we don't try to define the same scope type both using our legacy node matchers and the new query scope handlers
I have mixed feelings about the way I made this work, but I wasn't sure how else to do it. The test needs to be defined in the engine, because otherwise we'd need to expose lots of stuff to cursorless-vscode-e2e, but it needs a full tree-sitter instance, so can't be run as a unit test. This file is the compromise I came up with 🤷♂️. We should maybe revise once we have tree-sitter integrated with this repo
I don't like that this code gets rolled up into our production bundle, but probably ok for this one-off. If we find this file growing, we should revisit
It's also possible that once we get rid of our
ide
singleton, we can relax the restriction that our test harness doesn't import fromcursorless-engine
. That would enable us to just import what we need from the engine directly in the test harness to run this test 🤔Checklist