I tried to introduce tests to one of the team I worked at. I was somewhat successful in the end but it took some time and effort.

Basically, I made sure to work with the people interested in testing their code first. It's good to have other people selling testing instead of being the only voice claiming testing will solve ~~all~~ some problems.

Then I made examples: I tried to show that testing some code, believed to be untestable, was actually not that hard.

I was also very clear that testing everything was not the end goal, but, new projects especially, should try and leverage testing. Both as a way to allow for regression testing later on and to improve the design. After all, a test often is the first user of a feature. (This was for internal libraries, I expect it would be a harder sell for GUI where the end design might come from a non programmer such as a UX designer).

At this point, It was seen as a good measure to add a regression tests for most bugs found and fixed.

Also, starting from the high level, while harder (it's difficult to introduce reliable integration and end to end tests), usually yields benefits that are more obvious to most. People are much less nervous reworking a piece of code that has a testing harness, even if they are not in a habit of testing their code.

I did point at bugs that could have been easily prevented by a little bit of testing, without blaming anyone. Once the framework is in place and testing has already caught a couple of mistakes, it's much harder to defend the argument that time spent testing could be better spent elsewhere. And that's where we started to get discussions on the balance to strike between feature work and testing. It felt like a win.

It took two years to get to a point where most people would agree that testing has its uses and most new projects were making use of UT.