thanks for your criticism!! Yes, I see how that could be a problem. The prolog problem I would fix by having the parser use an XML parser, so that invalid xml would cause an exception. But I could get that also by testing the XML against XPath queries, as Jacopo suggests in the next post.

YMMV, but I still think it’s valuable to write code to extract the information from the xml and check this information. The extraction code could be a separate class, or private testing methods inside the test class.

I see how it would be valuable to *also* have a check that the syntax conforms to what I expect. But that would be a *testing* test, not a TDD test. I think that tests with serialize-then-parse would be better for driving the design.

this time I partially disagree with your point. Well, if it’s obviously a bad practice to test the raw XML string since, as you pointed out, it would create a really brittle test, I don’t feel comfortable with your solution.
First of all, I entirely agree with Jacopo’s annotations. But what I would underline here is that you wrote what I call an “ever green test”. I mean that your test could be successful even when both XmlSerializer and XmlParser are wrong, if the mistakes in the two classes are symmetric. Think, for example, to the case of the broken XML prolog you showed: if both classes use a broken prolog, they will talk each other, but they will never talk to anyone else. Or you can think of both classes serializing and de-serializing decimal numbers using comma as a decimal separator, as in the Italian convention (I really did this mistake, so I’m pretty an expert ;-) ).
You said that in your use case the two classes need to talk to each other and not to the rest of the world, so my annotations could be of no interest, anyway I think we need to take care of “ever green tests”.

My answer got so long that I made a new post about it :-)

but is far more common a scenario where webservice aren’t under your control, they represent and integration point with external systems: that is, XML document syntax _is_ what you’re trying to test. for example, (I can think of at least 2 cases that happened to me in the last 6 months) switching from one parsing library to another or simply testing interoperabily (such as Java/.NET).

of course, not as much domain logic there ;) but still, webservices aren’t supposed to encapsulate domain knowledge, so focusing on syntax would be good enough.