Issues running ALL tests with IC 1.0
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.
Comments (21)
-
repo owner -
reporter - attached idea.log
Log of issue reproduced with unit testing debugging
Unit Testing #com.illuminatedcloud.intellij.unittest.ApexUnitTestRunProcessHandler #com.illuminatedcloud.util.VariableLengthPollingInterval
-
repo owner 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?
-
repo owner 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. -
reporter 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.
-
repo owner 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.
-
reporter Explicit test configs are working fine for the time being thanks!
-
reporter 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. -
repo owner 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. -
reporter
-
repo owner Okay, thanks. Yeah, I'm not seeing the namespace prefix, e.g.,
dlrs_GS_Solicitation_ObligationTest
instead ofdlrs.dlrs_GS_Solicitation_ObligationTest
. Let me see what might be going on. -
repo owner 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?
-
reporter - attached Regenerating_OST_screencast_IC1.mp4
- attached OST_from_IC1.png
From my IC1.0
I’ll be attempting and attaching the same with my coworker experiencing the same in his IC2.0 shortly.
-
repo owner 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
anddlrs_GS_Project_Budget_LineTest
. Certainly the names would support that assertion. I think I incorrectly jumped the gun on thedlrs_*
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.
-
reporter 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.
-
reporter I Just selected the DLRS prefixed classes, and Triggers, saved(deployed) and now all tests are working.
odd…
-
repo owner 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.
-
reporter 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!
-
reporter - changed status to resolved
Resolved.
-
repo owner You bet! Glad it ended up being something so relatively benign in the end...
-
repo owner - changed component to Apex Unit Testing
- Log in to comment
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)?