It’s very hard to start writing tests for a codebase that was not tested while it was being written.

“Be more careful” is obviously just wishful thinking, but the pain apparently hasn’t become bad enough for the need to better quality to have become apparent to everyone.

When people say “we can’t test the UI”, there’s often a reason that they are reluctant. One reason can be that they think you want to test through the UI, and write slow and cumbersome end-to-end tests. Those tend to become unmaintainable at record speeds, and if you’ve experienced the amount of work and aggravation that can cause, you tend to become reluctant. When you ask for ‘integration tests’, this might be the thing people are hearing.

That being said, there’s plenty of ways to test UI code locally, at the unit and component level. Depending on your tech stack, of course. Those types of tests you can just start creating without a big investment. In a codebase that’s not tested, that can be difficult, but try and make the changes you need to make to isolate logic, so it can be tested as a unit test. It’ll give you better code, and teach you a lot about structuring code so that you separate responsibilties.