Timeline for Code coverage failure - Just what I'm uploading or entire org
Current License: CC BY-SA 3.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 27, 2014 at 4:12 | comment | added | Nathan Williams | The regular test runs are one of the best things you can do for yourself. There is nothing worse than not having run them for 6 months, having made myriad declarative changes, then one day go to deploy a new changeset and realize that one (or more) of the changes you made over the 6 mo period broke something and caused code coverage to come crashing down. Good luck troubleshooting for the next two weeks. I highly recommend building an automated test solution which tests daily. I built one that's caught a couple of issues overnight, so there was little-to-no guesswork on what to rollback. | |
| Nov 26, 2014 at 22:54 | comment | added | cropredy | ah ... right, run all tests from DC does in fact create separate log file per test class. I was thinking about when I used to deploy from sandbox to PROD via Eclipse IDE and if the deploy failed, the logs for all testclasses were in one log and for me, always > 2MB; I fixed the answer. thanks as always sfdcfox for keeping me accurate | |
| Nov 26, 2014 at 22:52 | history | edited | cropredy | CC BY-SA 3.0 |
removed error
|
| Nov 25, 2014 at 6:26 | comment | added | sfdcfox♦ | Minor points: Each class gets its own logs. This can sometimes help. Also, consider any new validation rules or workflow rules created or updated since the last deployment. They are usually the cause. It helps to periodically run all tests so you don't get caught off guard when you need to deploy. Where I work, we wrote a daily scheduler that runs all tests and emails the results back to the team so we can fix problems before they halt a deployment. | |
| Nov 25, 2014 at 1:46 | history | answered | cropredy | CC BY-SA 3.0 |