'Instantiating Tests' perpetually spins when test is run

[Matthew Chevalier]

This issue has been persistent for the last week for me.

‌

[Scott Wells]

Hi. It looks like perhaps the unit test run configuration may be pointing at a stale connection:

2022-10-13 17:55:49,062 [  83483] SEVERE - #c.i.o.a.i.ApplicationImpl - No Salesforce connection found for project ASR with name ASR-DEV-Matt and type OAUTH.
java.lang.IllegalStateException: No Salesforce connection found for project ASR with name ASR-DEV-Matt and type OAUTH.
    at com.illuminatedcloud.intellij.runconfig.AbstractApexProcessHandler.getConnectionConfig(SourceFile:91)
    at com.illuminatedcloud.intellij.unittest.ApexUnitTestRunProcessHandler.lambda$startProcessing$7(SourceFile:433)
    at com.intellij.openapi.application.impl.ApplicationImpl$1.run(ApplicationImpl.java:297)
    at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539)
    at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
    at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
    at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
    at java.base/java.util.concurrent.Executors$PrivilegedThreadFactory$1$1.run(Executors.java:702)
    at java.base/java.util.concurrent.Executors$PrivilegedThreadFactory$1$1.run(Executors.java:699)
    at java.base/java.security.AccessController.doPrivileged(AccessController.java:399)
    at java.base/java.util.concurrent.Executors$PrivilegedThreadFactory$1.run(Executors.java:699)
    at java.base/java.lang.Thread.run(Thread.java:833)

You might use Run>Edit Configurations to find the Apex Unit Tests run configuration being executed and make sure it’s pointing at a current connection for the project.

[Matthew Chevalier]

Deleting all of the old configurations (which were just single test classes that were saved for some reason) then selecting 'current file' here fixed everything. [cid:[e-mail]5A52D0]

Thanks for the help! Issue seems resolved to me.

[Scott Wells]

Okay. I’m going to leave this open and see if I can reproduce this behavior. Needless to say, the underlying issue isn’t being surfaced to the user in a very useful manner. It’d be much better if I could minimally tell the user what’s going on--and stop that interminable test run!--and also perhaps guide the user to a solution.

[Matthew Chevalier]

This problem arose for me again after the most recent update.
Following the instructions you provided before, I just opted to delete all existing run configurations and make a new one.
That fixed my issue.

[Scott Wells]

Hi, Matthew. Nothing changed in the area of testing in the last several releases except for #2296 which was delivered in 2.2.5.4. All that does is promote execution of exceptionally large numbers of test methods in a single test class to execution all all test methods in that class to work around an internal server error. My guess is that what you saw is an instance of the same issue as I haven’t addressed it (or reproduced it, but obviously it happens). I’ll try to take a look at it soon, though.

[Scott Wells]

This should have been resolved in 2.2.6.3 (next-to-last bullet item).