4

I have a question related to Salesforce.com Deployment. When we try to Validate/Deploy a new Change Set, am I right when I say that it will execute every single test affected by the Apex class / Visualforce page deployed?

(For example) If I insert/update/delete a record in my class, it will verify every single trigger associated (and their Unit testing) and make sure they do not return any error, have their assertEquals right and have at least 75%?

If not, is it executing EVERY test class in the organisation?

Improve this question

1 Answer 1

Reset to default
8

Simple answer - it will execute every test class. If you're coming from Java environment and are hoping for recompilation/retest of only affected packages - dream on ;)

A bit more advanced answer - it will skip tests inside managed packages (if you have any), it will execute only "your" unit tests.

There were some talks about rapid deployment that'd fire only related changes (can't seem to find a link now) but the way I understood it it was bit useless anyway (it required 100% sync between orgs apart from changes being deployed. So if you've added a new field or report to production but not the sandbox - full retest, baby).

Improve this answer
3
  • So if there's a new validation rule in production not compatible with some test class, it will require patching those test from the sandbox + re-deploy, otherwise it will prevent ANY other deployment?
    – jpmonette
    Feb 19, 2013 at 21:30
  • Yup. Every new validation rule, uniqueness constraint, marking field as required on field level (not on page layout), any previously deployed trigger that uses addError() etc are a risk. Or should I say - "SF will do their best to validate whether your custom functionality still works as expected with the set of changes you're trying to push now."
    – eyescream
    Feb 19, 2013 at 21:33
  • 3
    That is exactly correct. No unit tests (outside of managed packages) can be failing in production for a deploy to occur. If a new validation rule is in place that breaks existing code, you must fix that in your deploy as well. By the way, as a best practice, everything should be done in a QA environment before prod (including workflow/validation rules/etc). Even if it doesn't require code, it could break functionality. Putting it in QA first will allow you to test those changes before they are live in your prod environment.
    – Jesse Altman
    Feb 19, 2013 at 21:34

You must log in to answer this question.

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