1

I recently removed a trigger and an apex class from my Sandbox environment, along with the tests for these files. I am attempting to deploy to my production instance, but when I do the deployment tests fail attempting to run the tests for the classes that have been deleted.

  • I removed the tests from my test suite in Production
  • There is no reference of the trigger or class or its tests in my project/main/default folder

Why is it attempting to run tests for files and tests I've deleted?

2 Answers 2

1

They're still being run because your trigger and tests still exist in production.

SFDX (and deployments in general) don't support specifying test suites to run (which is a shame). You're generally either going to be running all local tests in the org (i.e. running everything except tests for managed packages) or specifying an exhaustive list of tests that you want to run.

The SFDX team has indicated that they will support destructive changes for force:source:deploy, but there hasn't been any communication about that in over a year, so...

It appears that you'll need to go through the metadata api (likely via ANT or force:mdapi:deploy) to delete your items in production.

This related question provides some alternatives (use unlocked packages or an NPM plugin by gdman)

1

Deleting the files from Sandbox or your Git project doesn't remove them from Production. You can't use a Change Set, either. You will need to use a "Destructive Changes" deployment to remove the code from production permanently. In DX, you might consider creating an Unlocked Package (that includes the files to delete), install it, then create a new version without the files (thus causing a delete) when you upgrade the package. You can read this answer of mine for more information.

Alternatively, if you just want to get it done, you might go straight to this Q&A that demonstrates how to use destructiveChanges.xml and SFDX, which is pretty straight-forward if you already have SFDX available. Just create two manifest files, then deploy them with force:mdapi:deploy.

Third, you can use the "No Software" solution that I outlined here, again with destructiveChanges.xml. It's an older post, but it gets the job done in just a few minutes with minimal effort. Really, it's kind of the same thing as the solution in the above paragraph, but uses the Developer Workbench to get things done. There's a free, hosted version of the DW here.

1
  • Such a complicated process for such a simple action
    – BlondeSwan
    Commented Jul 9, 2021 at 20:50

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .