You’re going to want to follow the “campsite rule” everywhere you go, and also sneak in positive refactors into your feature changes (if business is not willing to commit time to improving the maintainability of the codebase).
Read up on good software design principles. I don’t know you experience level, but for instance, everyone agrees that appropriate abstraction, and [encapsulation](https://en.wikipedia.org/wiki/Encapsulation_(computer_programming) make code easier and more enjoyable to work with, and will let you run tests on isolated sections of the code without having to do a full end-to-end testsuite run.
Having tests that you trust that, especially if they execute quickly will increase your “developer velocity” and allow you to code fearlessly, knowing that your changes are reasonably safe to deploy. (Bugs and escaped defects will happen, but you just fix them and continue on.)
You’re going to want to follow the “campsite rule” everywhere you go, and also sneak in positive refactors into your feature changes (if business is not willing to commit time to improving the maintainability of the codebase).
Read up on good software design principles. I don’t know you experience level, but for instance, everyone agrees that appropriate abstraction, and [encapsulation](https://en.wikipedia.org/wiki/Encapsulation_(computer_programming) make code easier and more enjoyable to work with, and will let you run tests on isolated sections of the code without having to do a full end-to-end testsuite run.
Having tests that you trust that, especially if they execute quickly will increase your “developer velocity” and allow you to code fearlessly, knowing that your changes are reasonably safe to deploy. (Bugs and escaped defects will happen, but you just fix them and continue on.)
Good luck!