What can you do about the quality of existing integration and unit tests while being the new guy in a team ?

Question

A recurring theme that I came across in my career is being the new developer to arrive in a team, and quickly having an inherent distrust of the existing unit and integration test suites.

During the interview you are told by the management that they "strongly support unit testing" and that they openly encourage it. They do, but everything about the tests themselves is just plain wrong. Like the fact that they are claiming 100% coverage when there is 100% integration test coverage but less than 10% repeatable unit test coverage. Some other problems I have found:

1. No clear indication between what is a unit test and what is an integration test. Unit and integration tests are mixed together in the same class.

2. Integration tests that have undeclared explicit dependencies on very specific dynamic data on a specific environment's database.

3. Non-transactional integration tests, basically tests that may or may not bother to clean up after themselves, sometimes requiring manual database "scrubbing" to make the test repeatable.

4. No mocking whatsoever, and application code requires a major overhaul just for mocking to be possible. In other words, design without testing in mind.

5. No clear naming conventions to quickly look at a test name and determine roughly what tests are being done.

This is all not to say that ALL of the tests are useless or bad, a good deal of them are pretty good and worth keeping, but it feels like panning for gold sometimes. I would purposely avoid running tests just because I was afraid of screwing up the database for my black-box test cases.

This has essentially given me an inherent mistrust of unit and integration tests that I have not personally written or reviewed in some way. At some level if you don't have faith in the quality of your test suite then it really brings no value to the team or the project whatsoever.

What do you do when you find yourself in this situation? What do you feel the best plan of attack would be to tackle something like this?

Should all of the tests be refactored in a monumental effort spanning across releases? Should you just abandon the idea that this legacy project may have one day solid unit test coverage?