"Improving the quality of our software" is the one I tend to use, but it's so vague. How will unit testing convert into cold, hard cash is what upper management want to know.
You don't give reasons for using an ORM in your code, do you? You just do it as part of your development work. It's nothing that's being questioned by PHB's.
Writing tests is (or should be) part of your development work.
Make sure you include the time it takes to write the tests in your "time estimate".
If I am estimating how long the work will take, I am estimating how long it will take to get the functionality working correctly with X% confidence it works correctly when the product ships. Unless “X” is less than 50%, automated testing is part of writing the code, not a nice-to-have.
“Improving the quality of our code” does sound vague, kind of like arguing how many knots are permissible in a plank of wood destined or a kitchen floor. Instead, I would simply explain that these tests I write are part of writing the code, and to explain that if management want the code without the tests, they need to tell me in writing that they are ok with a confidence level hovering around 50%.
I am not kidding about this number. I may deliver code that appears to do what it is supposed to do, but my experience is that either it is broken in ways that a simple QA test doesn’t show, or somebody (somebody else or even me next week) is going to regress it between now and when the product ships. Automated tests give me the confidence that it works, works correctly, and will continue to work correctly.
Having sat through an hour long lecture on lumber grades in a scenic construction course, let me tell you, it is anything but vague.
The best you might do would be to come up with examples of people who used unit testing and things came out beautifully because of it. Things rarely turn out that beautifully without testing, so it can be pretty convincing to anyone who has dealt with software development for any length of time.