I've been through this before (and I'm working through the tail end of it now), so I'll share a few things I've learned along the way.
You are not alone.
IME, the situation you've encountered is the rule, not the exception. I think you're tremendously privileged that you've managed to become a senior developer and have never encountered this. I think that part of your frustration is you're holding your actual team up against the idealized version of a team from the blogosphere, and the complete mismatch makes you question your sanity or theirs.
You need to throw out all your assumptions about what will and won't motivate your teammates, what they know and don't know, and especially you can't assume they'll just take it as read that they should follow good practice.
Your problem isn't technical, it's political.
The reason there aren't any standards is because no one wants to be responsible for creating, maintaining, and enforcing them. The reason no one wants to talk to anyone is that they can't imagine a world where they do anything differently, so what's the point of talking about it? No, I don't understand how you have a team of programmers who can't imagine different ways of doing things, but I've seen it often enough that I know for sure such teams exist.
To resolve this, you're going to have to assume some sort of leadership. This is politically difficult, because you are the newest member of the team.
You need to win trust.
The first thing you need to do is build trust on the team. I'd suggest starting with management, because I think your coworkers are already finding you threatening to their cozy world view.
Really listen to everything he says about future plans and expectations for the software. I think you'll find that you have openings for "You want me to do X, but this is in conflict with the existing practice on the team to always do Y. Which is the priority?"
Be alert for places that requirements are just getting dropped because everyone involved (including your CTO) sort of knows where the mines are and subconsciously sidesteps them. These are places where you can step forward and say "I think if I too two weeks to refactor this subsystem, not only could we do that requirement that everyone says is so hard, but I think I can probably fix recurring problem Z." And this is how you get to have your own rock-solid subsystems like Adam V suggested.
Once you have a rock-solid system, leverage it to be able to provide accurate estimates--something I guarantee your teammates can't do. Nothing endears you to a manager like giving him estimates he can take to the bank.
Be aware that this first step of getting your own subsystem will be much easier than getting other people to change, so don't get overconfident when it happens. Equally, don't get overly discouraged when you realize that everyone is quite happy to let you do what you want as long as they don't need to do anything differently.
Learn the current system
You're not going to know where you can confidently refactor until you've gotten at least a basic feel for the current system. I think at least part of your problem is that you were deceived by the interview process by thinking you could just jump in and start writing good code and get complete support.
You need to figure out how to work within the current coding style at least long enough to develop some domain knowledge and a feel for where the mines are. This will also allow your coworkers' hackles to go down a bit. Learn to use grep and other tools to find those "hidden" minefields. No matter how bad code is, there's usually a way to find a thread and pull it out far enough where you can find the other end. Look at this as a way of developing those debugging skills in ways a "better" team could never hope to provide you.
This will show you where "seams" exist that you can tie into or places that seams could be made with relatively low risk.
Clarify expectations
Go back to the person who hired you for your TDD and other expertise. Don't gripe about how you're not even able to even use these skills. Instead, ask questions that give you insight into this person's thought process. They probably think your course of action should be obvious (either because it is to them or because you're an expert in one area and hence should be expert in everything so it should be obvious to you), and you don't want to disappoint them and wind up getting fired.
Some example questions I might try in your shoes:
- The existing team isn't using Test Driven Development. Did they specifically ask for someone to be hired with these skills?
- What sort of timeline are you thinking I should be looking at to try to implement these new practices?
- How much support are you willing/able to give me in instituting this change?
etc.
One thing that I realized in my own situation is that, just as I sometimes don't have a clear understanding of how my manager envisions these things playing out, he often doesn't know what I need from him either. So if I send out an email to the team asking that we change practices, I might follow it up with an email to him asking for his explicit support and tying that to a specific goal he has set for the team.
This process takes time
It can take up to two years to build your credibility on this type of team to the point where you can start to shift the culture. So if for whatever reason you know now that your time frame with this team is shorter than that, you may want to consider moving on to a team that has better appreciation of what you bring to the table. However, if you stay and manage not to get fired as a bad fit, you will learn rare and valuable people and leadership skills that will serve you well into the future.
TL;DR
Often, whether a suggestion succeeds or fails comes down not to what you say but how you say it. I find that asking lots of questions works for me. "If we take this approach, how does that affect our ability to add feature A that we know is coming?" This leads people to the answer themselves and helps you avoid looking arrogant. Even more importantly, unless you are completely perfect you will be wrong some of the time. Asking these types of question gets to the meat of the matter without everyone taking a stand they then have to defend, so you don't wind up with a position you've fiercely defended where you turned out to be wrong.
I find in particular that phrasing things "Why wouldn't it work to do B instead of C?" works very well, because it puts the onus on them to come up with justifications for why you can't do something. For the team you've described, likely this isn't their forte. However, even if they can completely shoot your idea down, that's terrific! You've gained valuable insight into the problem, and you can make a different suggestion.
"more than 100.000 classes"Whomever designed this should be blacklisted so that they never get a job in IT ever again.