I'm working on a legacy software project right now. It consists of a lot of mostly undocumented classes. There are no unit tests and the project has enormous technical debt *(copy-paste classes, missed abstraction opportunities, 100 liner methods and 5000 liner god objects...)*. There are two other programmers in the team who are working on the project since the start. There were some other developers working on it but they all left (for reasons unbeknownst to me).

I was chosen by the management after an interview because I use/used TDD in my work, I have in depth knowledge of unit testing and I'm willing to work on a web application which has humongous load on it. Based on the interview I thought that they are putting the industry's best practices to good use but in fact it is quite the contrary.

My problem is that I either have to spend a lot of time on a feature in order to make it work or risk introducing a bug because the existing code is hard to test properly. Since I lack documentation and my teammates aren't really helpful either I sometimes step on "mines" left in the code by previous developers (undocumented side effects mostly or hidden rules which only someone with in depth domain specific knowledge can know of). These together began to reduce my reputation towards the two other developers I have to work with. 

My question is how can I convince the management/other developers that we need efforts to clean up the technical debt and write documentation for the features so a new developer on the project can get going easily? Given the situation above they don't really trust me and I have no options to justify any ideas I have because we have no metrics/code quality tools/management tools which can be used to objectively assess the situation. From their perspective everything on the project is just *good enough*.