Problems running Apex unit tests in non-namespaced Developer Edition orgs.

[Tom Fuda]

I upgraded to the latest version of Illuminated Cloud yesterday (2.1.3.0). I then noticed that whenever I tried to run an Apex unit test from within IC, I’d get an error like “INVALID_INPUT: This class name’s value is invalid: PatronTicket.MyTestClass. Provide the name of an Apex class that has test methods” The problem is that IC is trying to run a class with the namespace “PatronTicket” but this is a non-namespaced Developer Edition org.

I need to provide some background here: We’re an ISV. We develop managed packages, one of which has the namespace “PatronTicket”. For many years we used non-namespaced Developer Edition orgs to do all of our development work, deploying our code to the namespaced packager org whenever we need to create new versions of our applications. Over the past year or so we’ve transitioned to using SFDX and scratch orgs for some of our development work and CI set up. So, our IC projects contain an sfdx-project.json file for scratch org development. However, we still frequently develop in our classic DE orgs as well (due to shortcomings of scratch org development that I won’t go into here). Up until I upgraded to IC 2.1.3.0, we had been authorizing our DE orgs using “sfdx force:auth:web:login” to create an OAuth connection to the org. I then use this OAuth connection within IC to connect to the org. Now, it seems that in version 2.1.3.0, when I try to run a unit test, IC is picking up the namespace value that is specified in the sfdx-project.json file, which looks like this:

‌

{
  "namespace": "PatronTicket",
  "packageDirectories": [
    {
      "default": true,
      "path": "force-app"
    },
    {"path": "sfdx-common/force-app-common"},
    {"path": "force-app-bootstrap"}
  ],
  "sfdcLoginUrl": "https://login.salesforce.com",
  "sourceApiVersion": "48.0"
}

You can see that it has picked up this namespace in the connection: https://www.screencast.com/t/hnxRuaps0Zxw.

I was able to work around this by doing the following:

1. Create a metadata API connection to my DE org with username, password and security token.
2. Temporarily delete the sfdx-project.json file from my project directory.
3. Change the module connection from the OAuth connection to the metadata API connection.
4. Restore my sfdx-project.json file.

Step above 2 is necessary, because IC won’t allow me to select a metadata API connection if sfdx-project.json is present in the project’s root folder.

I realize we’re sort of in this half-way place between classic metadata/tooling API development and SFDX development, so I’m not really sure how many other users would experience this, other than my colleagues that are also development on the same projects as me. I’m not sure if there’s anything you can do about this, but it definitely seems like something changed in 2.1.3.0 that caused this to suddenly become a problem. We’ve been working with this project structure for nearly a year now, and were able to run Apex unit tests previously.

[Scott Wells]

Sorry for the issue, Tom. I'll take a look at this at the beginning of next week given that you have a workaround, albeit cumbersome, and I'm about neck deep in Summer '20 updates. I'll let you know about my progress via this ticket.

[Tom Fuda]

FYI, I believe someone else is hitting this issue and reported it as issue #1682.

[Tom Fuda]

FYI, I believe this is no longer an issue. Not sure exactly when it got fixed, but I am finding that I don’t need to use this workaround that I provided back when I filed this ticket. I can use the OAuth connection to connect to my non-namespaced DE org, and the unit tests run successfully. This probably means the #1682 is also fixed.

[Tom Fuda]

Seems to have gotten fixed as a side-effect of other changes since the time this was filed.