You should first establish yourself as a productive member of the team. No one is going to want to hear about how they could do things better from someone who just started. Once you have credibility and maybe some allies you'll want to have some evidence to support any new processes or workflows. Anecdotes about how you did things at other jobs won't carry a lot of weight.
The problem with software development techniques and tools like automated testing and style guides is that while they look like good ideas, and work at some places, there's not a lot of empirical evidence to support claims that automated tests will improve developer productivity or code quality.
Programmers usually perceive any new code base as crap in desperate need of new ideas and tools. It takes a while to get into a code base and really understand it, and by that time some things that seemed terrible or confusing at first will make sense.
The problem with software development techniques and tools like automated testing and style guides is that while they look like good ideas, and work at some places, there's not a lot of empirical evidence to support claims that automated tests will improve developer productivity or code quality.
Programmers usually perceive any new code base as crap in desperate need of new ideas and tools. It takes a while to get into a code base and really understand it, and by that time some things that seemed terrible or confusing at first will make sense.