Indeed, this is an example of how testing strategy influences design choices. I remember this especially when trying to write automated tests for transitions between web pages 20 years ago. I realized that it would help to design the web pages in a way that makes them less dependent on the path taken to arrive there—and that seems quite obvious in retrospect, but it didn’t seem obvious at the time. This was we could treat a Workflow as a sequence of individual Steps that were easier to test with unit tests. Having clear State Transitions in the style of a finite state machine makes it easier to notice when we’ve introduced annoying assumptions about global state that affect our ability to “jump to the middle” of a Workflow. This encourages us to have less of that global state, but instead to design that as temporary inputs to a page, such as HTTP Request Query Parameters.
We then only need Workflow tests if we feel any doubt about whether we’ve correctly assembled a sensible Workflow from the Steps. (If I feel such a doubt, that nudges me to clarify the inputs to and the outputs of a Step.)