The original goal for my team was to transmit a datastructure over the wire. The format of the serialized data structure was not important, as long as it could be parsed reliably.

What I mean to say is that even if your job is to develop the server side only, the value from your web service comes from being able to deserialize the data structure and do something with it. This is why I may write a deserializer anyway.

The team I was working with was happy with testing against a literal string, though. It will take a bit of time until they realize the limitations. The tests they have, crude as they may be, are still good enough for them to drive development.

“This sort of tests supports incremental development. If my data structure was, for instance, a list, I could write a nice sequence of tests:
* serializesAndRebuildsEmptyLists
* serializesAndRebuildsSingletonLists
* serializesAndRebuildsListsOfManyElements”

this still stands for syntax-checking tests (sticking with client code), where you’d probably assert, incrementally:

assertDoesNotContain(“<el&gt", s.serialize(emptyList));
assertContainsTimes(1, “<el>A<el>", s.serialize(listWith("A")));
assertContainsTimes(2, “<el>A<el>", s.serialize(listWith("A", "A")));

or even better, with XPath:

assertCount(0, “//el", s.serialize(emptyList));
assertCount(1, “//el[@text='A']", s.serialize(listWith("A")));
assertCount(2, “//el[@text='A']", s.serialize(listWith("A", "A")));

I was just stating that serialization/deserialization tests do not focus on intended goal for that piece of code: send XML data to a webservice.

when you say:

"Note that this test is robust, as changes of the intermediate representation will not break it. […] we could change it to byte array, or anything else, with no need to change this test"

it was not clear to me why would you change such representation, given XML message forwarding was the original scope.

but you're probably right: I would probably use a subset of coarse-grained (integration) tests for driving development of such piece of code.

anyway, what feedback did you collected from last team you joined as a coach? did they find test-driving XML generation code useful?

what other tests would help you develop and design your code incrementally, as opposed to simply checking that it works?

assertContains(“<el>A<el>", xml);

from your previous post I thought your team mates were supposed to test-drive client code, to sent XML to webservice. so, examples I was thinking about were mainly related to that scenario: a (more or less) documented “contract” in terms of
* message syntax
* message data content

testing through a full serialization/deserialization loop would (probably) be too much, and not focused on task at hand: sent data to remote service.

asserting strict xml content would fail, as you noted, being fragile. but testing specific values, such as

assertContains(“A”, xml);

would probably be _good enough_. then, a final integration test, connecting to a remote service (or a fake local one, but through HTTP) would cast behaviour on stone, to be much more confidend.

what do you think?