You've just been hired by a company to work on an existing project. When discovering its code base, you realize the tests are very rare, even totally absent. You don't wait to discuss what you think a big lack with your boss. Unfortunately, you can't convince him whatever the argument you bring.and he digs in his heels: "Why waste time on something that does not add any value for the customer?"
If you comply, you will be anxious and scared each time you touch that very fragile app. But you're aware of the benefits of covering the code with tests, even writing them before the implementation. Not your boss. He hires you to do the job: developing an application. Developing is not only one monolithic task: typing code. It's also writing tests, thinking of design, communicating to write the user story.
Automated tests are an important component of the application, it's not a separate entity. Don't talk about it as a separated task. When developing, write test, write code as there are a same and unique task of the job. Your boss doesn't need to know about all the details or why did he hire you for your expertise?
You may say that it's daunting task to fully cover a pre-existing code base with tests. In that case, I generally write tests only for new code and for bugs discovered in pre-existing code base. It organically increases the test coverage step by step.
In the long run, you'll probably be able to explain the value to your boss - especially if you are actually doing it. One more reason to start today.