#32🚀 DeploymentAnnoying

Deploying Apex Without Including the Test Class

“Your deploy will fail at 75% code coverage if you forget the test class.”

What Happened

I wrote a beautiful Apex service class and its test class. Deployed the service class to production. Forgot to include the test class in the deployment package. Production code coverage dropped below 75%. The deploy succeeded but now I couldn't deploy anything else until I fixed coverage. Spent an hour troubleshooting why my next deploy kept failing.

The Wrong Way

# Only deploying the main class
sf project deploy start -d force-app/main/default/classes/OpportunityService.cls \
  -o production --test-level RunLocalTests
# Coverage drops below 75% because the test class isn't in prod yet
# Every subsequent deploy fails with: Average code coverage is below 75%

The Right Way

# project structure: keep test classes alongside source
force-app/
  main/
    default/
      classes/
        OpportunityService.cls
        OpportunityService.cls-meta.xml
        OpportunityServiceTest.cls
        OpportunityServiceTest.cls-meta.xml

# Deploy both together, always
sf project deploy start \
  -d force-app/main/default/classes/OpportunityService.cls \
  -d force-app/main/default/classes/OpportunityServiceTest.cls \
  -o production \
  --test-level RunSpecifiedTests \
  --tests OpportunityServiceTest

# Or better: use a manifest
sf project deploy start -x manifest/package.xml -o production --test-level RunLocalTests

The Lesson

Always deploy Apex classes with their test classes. Use package.xml manifests to ensure nothing gets left behind.

Share this mistake on X

Don't make this mistake.

Hire someone who already did.

View Consulting →

#31 Deploying to Production on Friday Afternoon Running Destructive Changes Before Deploying Replacements #33

Enjoyed this? Get more like it.

Glen's Musings — AI, investing, and building things. Occasional. Free.

More Deployment Mistakes

Painful

Deploying to Production on Friday Afternoon

Friday deploys turn weekends into war rooms.

Running Destructive Changes Before Deploying Replacements

Delete the old stuff AFTER the new stuff is live. Not before.

Skipping Sandbox and Deploying Straight to Production

If you didn't test it in a sandbox, you're testing it on your users.