Never is too harsh. Very often might be a more appropriate statement.
The point is: in order to do proper unit testing, you sometimes have to control the objects that your "class under test" is using. And when the corresponding field is initialized via a call to new()
... then you simply can't control that field. ( well, you could be doing that using bytecode-manipulating tools like PowerMock; but especially when writing your own code: then you absolutely avoid PowerMock; the need to use that indicates that you put down a bad design. Period )
Whereas, when you use dependency injection, then a unit test can pass a mocked object for that field into the class under test.
But please note: this is not only about "proper unit testing." There is an essential difference between A) initializing your business logic and B) your business logic doing its "business". Those are two different responsibilities, and when you are not clear about this separation, your product is much harder to maintain and enhance over time.
A good starting point to learn about this topic are these videos. Each one really worth each minute ...
EDIT: your comment/question goes quite far; and there is ton of existing material out there (like here, here, or there). But one general remark here: the essence of reasonable unit testing is ... to segregate your business logic into small, testable units!
What I mean is: when you push a lot of code into one class that does 5 different things, then writing good unit tests is hard. Instead: you create one unit for one responsibility. In your context: there could be one class for reading XML data. That class deals with XML, and returns something that is not XML any more. Then you have another class that works on the output created by the first class.
And about your second question: that really depends where your XML is coming from. In other words: your production code must be able to detect all kinds of bad XML input. Because you want your production code to correctly handle all input that could be given to it. So your the goal of your unit tests is to make sure that all validation that you put into place is actually working. It is not the job of your test code to validate XML! Unit tests validate that your code fulfills its contract!
And now, your unit tests focus on that: some tests make sure that this XML reading/transformation works; and other tests (that know nothing about XML) make sure that the further processing works.
But as said; this is really a very broad topic, and you shouldn't expect that a single SO answer can tell you all the things you need to do. This topic requires many months of studying all kinds of resources, and ... practicing, practicing, practicing...