We certainly make great use of XPath and use XMLUnit. I don't really consider the unit tests to be 'brittle' because tests fail when the structure, that's what I expect to happen in most cases. As per the *other* hot thread on-going, it also somewhat depends on the volatility or the message structures than you use. As Michael said, if your dealing with interfaces, then often a low rate of churn is preferred.
Of course it also all depends on how you write the XPath itself. If there are parts of the structure which I want to skip past then I might very write the XPath to do exactly that, as Mike says, focusing attention on the specific item of fragment that I am interested in. As an example, in some of our tests a exception response structure from a application can contain many nested levels of <RecoverableException> information which is akin to a stack trace. At the bottom of that structure there might be an element called <UserException> and if thats what I'm writing a test for, my XPath may look something like //UserException/blah. Whats wrong with that ?
> and work hard to make unit tests depend only on the component being tested
Yep, eliminating external dependencies is something that I subscribe to.
> IMHO, this encourages a culture of "fix it by randomly mutating the
code, and assuming you have it right when the
> unit tests pass", which is
downright scary.
Indeed, but that's a different problem than the one being discussed. IMHO that's about making sure that your tests are a demonstration of the business requirements and not a demonstration that some code does something successfully.
