This message was deleted.

good question! there’s a couple options: • if you’re adding new e2e tests, one option might be to split out your functional changes (potentially even into multiple PRs for easier review-ability) from the tests • if you’re modifying code that is already tested, making the logical changes iteratively, each with the corresponding updates to the tests, ensures that each PR in the stack is implemented accurately • if neither of those work, consider isolating your changes by creating a new logical branch/codepath which can be independently tested hope that helps! also, our very own @David Bradford wrote up this helpful guide about different stacking methodologies which might also be useful!

by a new "logical branch" or "codepath" do you mean a separate "dev" branch you rebase onto before rebasing onto main?

ah not quite~ i was suggesting that you could create new logic rather than breaking the functionality of existing code that way, the existing tests should still pass as the existing logic is unchanged, and you’ll be able to land/test/ship your new logic incrementally! this kind of flow would also jive with using feature flags to rollout the breaking change 🙂