The monolith, what used to be a bad word is now being remembered with fondness for its simplicity. Yes, there was often a big ball of spaghetti associated with such a time. This is where the testing pyramid shone. Those clean layers of testing, those clear responsibilities broken up between developers, automation testers, and manual testers.
Those of you who are not familiar with the testing pyramid will get the idea from the following diagram.
I used to swear by this concept, I would also hold teams to account on this almost like a religion. In a monolith based paradigm, this makes so much sense. The unit tests keep the developers honest and ensure they write clean code that adheres to SOLID principles, service tests were far simpler as you would have fewer dependencies – yes, you would still have external dependencies but you would have less of your own distributed dependencies to deal with. UI tests have always been hard, so keeping these to a minimum was a lifesaver.
There was of course arguments about what should be tested, what level should these be tested at, what level of test coverage would be required. Mature teams would talk these out reasonably and come to sensible decisions.