Cart
[Home] [By Thread] [By Date] [Recent Entries]
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. Yep, eliminating external dependencies is something that I subscribe to.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 > 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. On 10 April 2013 17:03, John Cowan <johnwcowan@g...> wrote:
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
