Running tests depending on TypeScriptStubs
I'm attempting to download and register a TypeScript-stub before running my tests. I'm using a custom ProjectDescriptor and the LightCodeInsightFixtureTestCase-class.
After much trial and error I got the following code to work when debugging the plugin:
DownloadableFileSetDescriptionWithUrl configLibrary = TypeScriptAllStubsFile.INSTANCE.getDownloadableFileSetDescription("config");
TypeScriptDefinitionFilesRootsProvider.LibraryCreator.downloadTypesLibrary(project, configLibrary, null, null);
I've two theories as to why the library remains unavailable within my tests:
1. The code-path for "downloadTypesLibrary" is littered with invokeLater(...) and the like. I'm thus unable to make the test-setup-method wait until the library has been installed.
2. The virtual-filesystem doesn't pick up the new library files and the library thus remains unavailable.
5 hours of reverse-engineering and code-decompiling later, I'm none the wiser. Much of the code is Kotlin which effectively kills my step-through-debugging.
Please help! :)
Please sign in to leave a comment.
Hi.
>The code-path for "downloadTypesLibrary" is littered with invokeLater(...) and the like
Yes, this code is started on a pooled thread (executeOnPooledThread) and after completion calls invokeLater() for updating the state. Also there are a lot of preconditions (node interpreter, internet connection) so we never run this code directly in tests. If you need it feel free to file an issue on https://youtrack.jetbrains.com/issues/WEB
I suspect I'm the only one with this need, so I will refrain from filing an issue at this point.
Since this code only affects tests, I will first attempt to hack together a way to wait for the thread-pool.
If that doesn't work I will copy-paste the code in question and run it synchronously.
Thanks for your help though! :)
Well... library installs, but it would seem it as no effect on the reference-resolving. It is associated with the project-module.
Any pointers?
Well... Don't know quite how, that's always reassuring, but the tests are running in a reliable manner now.
Here's a working solution.