You need to create a list of incidents that reached customers. Create a matrix that has the incident ID, the link to the incident documentation and the type of test that would have caught the incident.

Then they'll see that their incidents would have been caught by the tests you want to. push instead of an angry customer.

Show them the Beyonce Rule part of the Google SWE book.

We are often asked, when coaching new hires, which behaviors or properties actually need to be tested? The straightforward answer is: test everything that you don’t want to break. In other words, if you want to be confident that a system exhibits a particular behavior, the only way to be sure it will is to write an automated test for it. This includes all of the usual suspects like testing performance, behavioral correctness, accessibility, and security. It also includes less obvious properties like testing how a system handles failure.

We have a name for this general philosophy: we call it the Beyoncé Rule. Succinctly, it can be stated as follows: “If you liked it, then you shoulda put a test on it.” The Beyoncé Rule is often invoked by infrastructure teams that are responsible for making changes across the entire codebase. If unrelated infrastructure changes pass all of your tests but still break your team’s product, you are on the hook for fixing it and adding the additional tests.

What does "FE" stand for in this context? Sorry if it's obvious, I just don't see anywhere that it's actually written out.

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.

Just do it, whenever you fix a bug, add a test case for it, the cost is not going to be noticeable. You may choose to not upload the test suite right away, but wait until someone notices and asks you about it.

Just add them. You're a developer and automated testing is one of our tools. A woodworker wouldn't ask permission to sand.

who did you ask? Write the UI Tests for your debugged components anyway. Tests are part of development, and if you cant then you write your components wrong.

Don't. You really can't for most of it. At best, you can test whatever utility functions you have. The FE can and will break more in design than anything else, and that will never get caught by tests.

That said, try a wholistic approach. Playwright requires you to run the back end too, so you get a proper test suite going, instead of jest or whatever.

So you're probably not going to be able to swing getting a project greenlit to test everything on your frontend, partly because your management seems a bit stingy, and partly because it's probably not the best approach to do this kind of thing anyway.

To the claim of that you can't test UI: only if you're not creative enough. Behavior can 100% be tested, and is worthwhile to test, while UI looks can be verified with screenshot tests.

How I would probably approach this would be:

1. Get some very basic test execution infrastructure in place. Ideally it runs in CI, but if you have to do it in the dark, then just make sure you can run it locally
2. Try to refactor parts of the code you touch to actually have its behavior testable - do this as a part of any ongoing work of navigating the codebase
3. Whenever you add functionality, add a test to verify it. Write the test first if you can
4. Whenever you encounter a bug, write a test asserting the behavior you want, then fix the bug such that the test gets green.

Following these steps should successively put the codebase into a healthier state.

Another perhaps even more valid option would be to look for a better job - working in headwind from management is not recommended, as it will deteriorate your mental health.

Good luck!