How often have you hit a situation where you start deploying a new change set to Salesforce.com in production, and get stopped by errors on an unrelated test case? It’s certainly very frustrating when that happens – here’s one commonly encountered cause of such errors and what you can do about it.
Sometimes you might think that a small change involving adding a couple of new fields and a workflow should be very benign. Migrating that to production should be a breeze – and it goes all fine and you’re feeling pretty good until someone tries migrating another changeset with code, and start calling you about errors that are possibly related to the changeset that was deployed by you over a week ago.
It is not always possible to find references to the exact set of changes that may be impacted by your change. As systems get larger and more complex with a significant number of customizations and appexchange packages added in, one area where developers and administrators need to focus on better practices is with test cases. This is one frequent cause of errors that are brought into focus at an unexpected time.
To avoid surprises, one defensive tactic in SFDC is to run all test cases in your development and sandbox orgs even if you have not made any code changes before promoting your changeset to production. This should help you catch errors that will impact your test cases during deployment and allow you to resolve them before you upload your changeset.
