function readOnly(count){ }
Sign Up ›
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
Learn More

Browse by Topic
ShowAll Questionssorted byDate Posted
+ Start a Discussion
Jon SheaJon Shea 

Raise Code Coverage by replacing outdated code in Sandbox ?

Looking for some confirmation on this from the community. I have inherited an org with lots of outdated apex, and multiple changes to VRs, field requirements, field values, profile names, record type names etc. All of this was done without any insight into, or konwledge of, apex that had also been written many years ago. 

Production code coverage is now hovering around 40%...... 

Most of the existing custom apex is now irrelevant (outdated processes that are no longer used) and I need to get coverage up so I can begin to push change sets and update the existing org. 

Since my primary goal is to raise code coverage and then delete many of the existing classes, triggers, extensions, etc  my question is: Can I simply replace existing class code with simpler classes and test classes rather than dig through and update the existing code and configuration?

Again, the goal is to get rid of a lot of this code anyway so this seems like a quick and dirty solution to an otherwise overwhelming problem. 

Any thoughts?
Best Answer chosen by Jon Shea
pconpcon
Yes, you can replace the existing class code (as long as the you update the tests or ensure that the tests still pass).  If it is as bad as you say, then it might be worth deleting the code and the test classes instead of just replacing them.  If you want to ensure that you have the same expected behavior, I would write tests that verify that your code is currently working as expected.  Then I would update your classes to a better implementation to ensure that you do not break functionality.

All Answers

pconpcon
Yes, you can replace the existing class code (as long as the you update the tests or ensure that the tests still pass).  If it is as bad as you say, then it might be worth deleting the code and the test classes instead of just replacing them.  If you want to ensure that you have the same expected behavior, I would write tests that verify that your code is currently working as expected.  Then I would update your classes to a better implementation to ensure that you do not break functionality.
This was selected as the best answer
Jon SheaJon Shea
Thanks @pcon. Just getting started on the Dev side of things and I was thinking I had to get coverage to 75% just to be able to delete these classes - but it looks like there is an easier method through the IDE. Luckily most of the existing customizations related to custom objects that are no longer in use. Here's to hoping that deleting the legacy classes won't have much impact on day to day operations!

Appreciate the help.