One thing I like to add to this is that there is a cost of context switch (average of 15-25 minutes, depending on the study, and obviously varying significantly between types of tasks), and we lose focus when waiting takes more than 15s or 30s [citation missing, though you can look it up].
Slow feedback loop will add the above 15-20 minutes as soon as you switch to something else because it took more than 15-30s (on average, though).
I like to note that there are also people who are amazing good at both regaining focus, and not getting flustered by switching between tasks. I am not one of them, though :)
The SoA and the team structure often worsen this. If your service consists of AWS S3, SQS, MSK, and Kinesis, then you'd have to invest quite heavily in the local setup to make sure everything still works and that the majority of the tests can be run in a reasonable amount of time.
Of course, it's impossible to run the full fleet locally if it's a substantially large system, but investing in the local workflow for a particular domain is absolutely paramount. Otherwise, the context switch required to integrate and work with a system like this is absolutely massive, and the lead time for a new feature will take a major hit.
That's where we somewhat disagree on "invest heavily".
I believe you can test well enough by focusing on the semantic value an external service is providing (eg. S3 as a special purpose object or file storage with only a few operations, not a generic object storage; SQS could be a very simple event framework for most use cases), implementing only the very narrow use cases you need covered, and having a test which confirms that the simulated, local-only version behaves exactly the same as the one backed by the real service.
And really, with a well structured codebase, this should really not be very expensive.
The complexity really comes in with configurability, but as most components will really only depend on a few other (or your architecture is not well encapsulated), it shouldn't be too hard to run any individual one fully locally.
I am not saying this is "easy", but once you wrap your head around this approach, it's surprisingly simple and cheap: it provides just enough tests to cover everything, without covering many things with multiple tests (which also slows down development in the mid- and long-term).
In short, I have yet to see a software architecture that's inherently testable at all levels without it simply being a good architecture.
Readit News
Slow feedback loop will add the above 15-20 minutes as soon as you switch to something else because it took more than 15-30s (on average, though).
I like to note that there are also people who are amazing good at both regaining focus, and not getting flustered by switching between tasks. I am not one of them, though :)
Of course, it's impossible to run the full fleet locally if it's a substantially large system, but investing in the local workflow for a particular domain is absolutely paramount. Otherwise, the context switch required to integrate and work with a system like this is absolutely massive, and the lead time for a new feature will take a major hit.
I believe you can test well enough by focusing on the semantic value an external service is providing (eg. S3 as a special purpose object or file storage with only a few operations, not a generic object storage; SQS could be a very simple event framework for most use cases), implementing only the very narrow use cases you need covered, and having a test which confirms that the simulated, local-only version behaves exactly the same as the one backed by the real service.
And really, with a well structured codebase, this should really not be very expensive.
The complexity really comes in with configurability, but as most components will really only depend on a few other (or your architecture is not well encapsulated), it shouldn't be too hard to run any individual one fully locally.
I am not saying this is "easy", but once you wrap your head around this approach, it's surprisingly simple and cheap: it provides just enough tests to cover everything, without covering many things with multiple tests (which also slows down development in the mid- and long-term).
In short, I have yet to see a software architecture that's inherently testable at all levels without it simply being a good architecture.