Issues running ALL tests with IC 1.0

[Aaron Hallink]

Running specific sets of tests seem to be fine, but trying to run all tests I get lots of ‘ignore’ errors.
I have tried recreating OST, and recompiling all apex on the instance but I can’t seem to get it to work.

[Scott Wells]

Aaron, can you enable debug logging for unit test execution, reproduce the issue, and attach or email the resulting idea.log (Help>Show Log in Explorer/Finder/Files)?

[Aaron Hallink]

Log of issue reproduced with unit testing debugging

Unit Testing #com.illuminatedcloud.intellij.unittest.ApexUnitTestRunProcessHandler #com.illuminatedcloud.util.VariableLengthPollingInterval

[Scott Wells]

Thanks. Here's the issue:

2019-11-19 16:37:01,655 [  19264]   WARN - .ApexUnitTestRunProcessHandler - Unexpected status code 403 returned. 

The REST API call to run the is returning an HTTP 403/Forbidden. Unfortunately it's not including details about the exact nature of the error in the log, but it should be writing all of the response details into the test output console. If you select one of those failed test classes, what is in the output console view?

[Scott Wells]

Thanks. That explains what's going on. All messages like the following are sent back from the Salesforce API in response to the request to run tests:

Error 403/Forbidden - INVALID_INPUT: This class name's value is invalid: dlrs_GS_Solicitation_ObligationTest. Provide the name of an Apex class that has test methods.

It looks like you're running into an issue that I fixed in IC2 already where IC is finding classes/methods in the offline symbol table that include the testMethod modifier and is telling the server to include them in the test run. I'll need to back-port that fix into IC1. I'll see what I can do in the next few days. Keep an eye on this issue for progress on the fix and related plugin update. In the interim keep using your current workaround of explicitly selecting all local test classes/methods.

[Aaron Hallink]

My colleague is using most recent 2.0 and he is getting the same behaviour, I think the DLRS managed package tests are the ones that are causing issues.

[Scott Wells]

Thanks for the update, Aaron. I have DLRS installed in a few of my orgs. I'll make sure I'm on the latest version and see if I can reproduce it with both IC1 and IC2. That won't likely occur until the beginning of next week at this point because I'm leaving today with my family for Thanksgiving holiday. Hopefully the workaround of maintaining an explicit unit test config will be sufficient for the next few days until I can dig in and address this. I'll definitely prioritize it for the beginning of next week.

[Aaron Hallink]

Explicit test configs are working fine for the time being thanks!

[Aaron Hallink]

To make things stranger my coworker we just onboarded with 2.0, is having no issues with the all setting run against the org.
I’m on 1.0 having issues with it and my other coworker on 2.0 is also having issues with all.

[Scott Wells]

Aaron, do you have DLRS installed as a managed package or as raw source? I ask because in the information above, it appears to be the latter. Names like dlrs_GS_* don't include a managed package namespace. Let's start there and understand how things are installed. Then hopefully I can figure out if this is the same issue I fixed previously or something else.

[Aaron Hallink]

‌

[Scott Wells]

Okay, thanks. Yeah, I'm not seeing the namespace prefix, e.g., dlrs_GS_Solicitation_ObligationTest instead of dlrs.dlrs_GS_Solicitation_ObligationTest. Let me see what might be going on.

[Scott Wells]

Okay. I'm on the latest version and am not able to reproduce the issue. What do you see from the dlrs namespace in your offline symbol table? Here's what I see:

If you see some of these classes that are causing the problem, what happens if you regenerate your OST? Does that fix the issue or does it remain? How about the IC2 user?

[Aaron Hallink]

From my IC1.0

I’ll be attempting and attaching the same with my coworker experiencing the same in his IC2.0 shortly.

[Scott Wells]

Thanks. Perhaps I'm mistaken then. Perhaps you're naming your own classes dlrs_* for those that are implementations of the DLRS pattern, e.g., dlrs_GS_Solicitation_ObligationTest and dlrs_GS_Project_Budget_LineTest. Certainly the names would support that assertion. I think I incorrectly jumped the gun on the dlrs_* pattern previous assuming those were from the installed managed package.

Assuming that's the case, are those classes properly found in the server? Do the server versions match the local versions? You can use Retrieve for Merge to compare the two. Now I'm thinking that there's something out of sync local vs. server for these classes.

[Aaron Hallink]

Oh I believe once you create a configuration for DLRS, it dynamically creates the apex trigger and apex test class for the object. So we created those in the sense the package dynamically created them once the configuration was made.

‌

[Aaron Hallink]

I Just selected the DLRS prefixed classes, and Triggers, saved(deployed) and now all tests are working.

odd…

[Scott Wells]

Yeah, I think they weren't saved properly to the server. Not sure why that would be the case, but it would totally explain the behavior.

[Aaron Hallink]

It’s weird because I’ve definitely been retrieving them. But redeploying them fixed it for me and my other 2.0 user.

thanks for the help!

[Aaron Hallink]

Resolved.

[Scott Wells]

You bet! Glad it ended up being something so relatively benign in the end...