Rename refactoring doesn't update existing unit test run configurations

Issue #841 new
Komal T created an issue

I recently upgraded to version 2.0 and was able to run my Unit tests with coverage option from the Run Menu. Today, all of a sudden, I just kept getting the "Terminated" message when running the Unit tests with or without coverage.

If I click on the Left hand side "Run failed tests" or "Run Tests" from the Run Window, the tests run but when invoking the "Run TestClassName" or "Run TestClassName with Coverage" option from the Top Menu, the output window simply shows "Testing started at ... Using connection... " and then the test terminates.

I can confirm that nothing is wrong with my code because if I run the tests for the same from the Developer Console, they run just fine.

I have attached screenshot for the same.

I tried to regenerate the Offline Symbol table, etc. but the problem still remains. I wonder if this is a bug.

Comments (13)

  1. Scott Wells repo owner

    Komal, this is almost always the result of a bad compilation state on the server. Unfortunately there's no public API for IC to use to report on this, but you can go into the Web Setup menu and then into Apex Classes and click Compile all classes. If the server is in a bad compilation state, it should tell you the classes which have errors. Once corrected, the issue with unit test execution should go away. Please let me know if this doesn't help.

  2. Komal T reporter

    Thanks for the prompt response Scott. I did try that earlier because I found that solution in the FAQs but that didn't help either. I even restarted IntelliJ, regenerated Offline symbol table, Fetched Metadata, etc. in hopes that my local machine would fetch the correct information from the server and work, but that didn't help.

  3. Komal T reporter

    Thanks. Upon following the steps on that link and reproducing the issue, I see the following "403 Forbidden" in the idea.log:

    2018-01-03 20:08:19,248 [ 61052] DEBUG - .ApexUnitTestRunProcessHandler - Running tests for [ 04_MF1_CMO_DevPro_Sandbox: { CMOAssignCase2DBTC_Test } ]. 2018-01-03 20:08:19,348 [ 61152] DEBUG - ij.coverage.ApexCoverageEngine - Creating a new coverage suite for name = '04_MF1_CMO_DevPro_Sandbox Coverage Results' and connection name = '04_MF1_CMO_DevPro_Sandbox'. 2018-01-03 20:08:19,348 [ 61152] DEBUG - lij.coverage.ApexCoverageSuite - Created an Apex coverage suite with project name = 04_MF1_CMO_DevPro_Sandbox and connection name = 04_MF1_CMO_DevPro_Sandbox. 2018-01-03 20:08:19,413 [ 61217] DEBUG - .ApexUnitTestRunProcessHandler - Starting test run. 2018-01-03 20:08:19,414 [ 61218] DEBUG - .ApexUnitTestRunProcessHandler - Finding class declaration for CMOAssignCase2DBTC_Test. 2018-01-03 20:08:19,415 [ 61219] DEBUG - .ApexUnitTestRunProcessHandler - Finding test methods in CMOAssignCase2DBTC_Test. 2018-01-03 20:08:19,415 [ 61219] DEBUG - .ApexUnitTestRunProcessHandler - myTests is a test method. 2018-01-03 20:08:19,631 [ 61435] INFO - y.ReflectionServiceFactoryBean - Creating Service {urn:partner.soap.sforce.com}PartnerService from class com.sforce.soap.partner.PartnerApi 2018-01-03 20:08:22,270 [ 64074] INFO - cloud.client.ForceComApiClient - Login successful for connection '04_MF1_CMO_DevPro_Sandbox'. 2018-01-03 20:08:22,270 [ 64074] INFO - y.ReflectionServiceFactoryBean - Creating Service {urn:partner.soap.sforce.com}PartnerService from class com.sforce.soap.partner.PartnerApi 2018-01-03 20:08:22,467 [ 64271] INFO - cloud.client.ForceComApiClient - JAXB initialization for com.sforce.soap.partner.SessionHeader took 108ms. 2018-01-03 20:08:22,565 [ 64369] INFO - cloud.client.ForceComApiClient - JAXB initialization for com.sforce.soap.partner.CallOptions took 97ms. 2018-01-03 20:08:22,565 [ 64369] DEBUG - .ApexUnitTestRunProcessHandler - Creating a trace flag. 2018-01-03 20:08:22,917 [ 64721] INFO - y.ReflectionServiceFactoryBean - Creating Service {urn:tooling.soap.sforce.com}ToolingService from class com.sforce.soap.tooling.ToolingApi 2018-01-03 20:08:32,543 [ 74347] INFO - cloud.client.ForceComApiClient - JAXB initialization for com.sforce.soap.tooling.SessionHeader took 596ms. 2018-01-03 20:08:33,028 [ 74832] INFO - cloud.client.ForceComApiClient - JAXB initialization for com.sforce.soap.tooling.CallOptions took 485ms. 2018-01-03 20:08:35,728 [ 77532] INFO - .ApexUnitTestRunProcessHandler - Running unit tests asynchronously. 2018-01-03 20:08:35,728 [ 77532] DEBUG - .ApexUnitTestRunProcessHandler - Queueing the test run. 2018-01-03 20:08:35,740 [ 77544] DEBUG - .ApexUnitTestRunProcessHandler - Posting the following to runTestsAsynchronous: 2018-01-03 20:08:35,740 [ 77544] DEBUG - .ApexUnitTestRunProcessHandler - {"tests":[]} 2018-01-03 20:08:36,232 [ 78036] WARN - cloud.client.ForceComApiClient - Status code 403 returned trying to retrieve 'https://mailforce1--cmo.cs13.my.salesforce.com/services/data/v41.0/tooling/runTestsAsynchronous/': Forbidden 2018-01-03 20:08:36,232 [ 78036] WARN - .ApexUnitTestRunProcessHandler - Null async Apex job ID returned from queue request. 2018-01-03 20:08:36,232 [ 78036] DEBUG - .ApexUnitTestRunProcessHandler - Finishing test run.

  4. Scott Wells repo owner

    Ah....I think I know what's going on. You have some test class or method locally (in your fileystem) that's not on the server, and you're asking IC to execute that test as part of the run. You might verify that all of your local classes are deployed to the server and try again. Let me know if that doesn't help.

  5. Komal T reporter

    Yes, I verified that all test classes available to my project on my local machine are present in the Sandbox Org. In fact, I had started with a clean slate in a fresh DevPro Sandbox and the Test Class that is currently not being run with coverage was created today and it was working fine until afternoon when it suddenly stopped working.

  6. Komal T reporter

    Ok. So after much research, I did the following and was able to run the Unit tests again:

    1. Deleted all the entries under the Run > Edit Configurations > Apex Unit Tests Menu
    2. Added a new configuration and selected my Test Class to that configuration
    3. Re-ran the Test Class with Coverage option from the Run Menu

    I realized that the previous entries in my Edit Configurations (point# 1 above) had reference to an old method that was subsequently renamed and even though I never explicitly created the entries in the Edit Configurations section, and the fact that it was working just fine before leads me to believe that this must be a bug wherein the entries in Edit Configurations become "static" the first time they got created. BTW, I have been using the new Refactor > Rename feature available in the 2.0 version of Illuminated cloud to ensure that I maintain the integrity of my code.

    You might want to reproduce this problem to see if this is indeed a bug by taking the following steps:

    1. Create a new Unit Test Class
    2. Create a testMethod, say myUnitTests
    3. Run the Test Class with Coverage option
    4. Use the Refactor > Rename feature to rename the testMethod to myTests
    5. Save and re-run the Test Class with Coverage option
    6. Check if you run into this issue

    Thanks for your prompt responses Scott.

  7. Scott Wells repo owner

    Ah, wonderful! I'm glad you found out what was going on. Yes, that oversight is on my short list to address. I'm sorry that it bit you here, but the fact that it did so makes the need to address the oversight all that much more critical. I'll see if I can work it into one of the upcoming builds. Thanks for your patience in working through this!

  8. Komal T reporter

    Thanks.

    On a slightly different note, do you know how I can get the “Coverage” window to stay pinned and not get lost every time I “Run with Coverage”?

    Presently, even though I have the “Coverage” tool window pinned and docked, it always goes away every time in “Run with Coverage” and I have to keep bringing it back from the Tools Menu.

  9. Komal T reporter

    On a slightly different note, do you know how I can get the “Coverage” window to stay pinned and not get lost every time I “Run with Coverage”?

    Presently, even though I have the “Coverage” tool window pinned and docked, it always goes away every time in “Run with Coverage” and I have to keep bringing it back from the Tools Menu.

  10. Scott Wells repo owner

    Unfortunately I don't. I've seen the same behavior. It's supposed to open up when you show a coverage suite but it doesn't. I've logged a bug with JetBrains about it but we haven't figure out why it behaves that way. I'll keep looking into it and hopefully find a solution.

  11. Log in to comment