So i took a stab at refactoring it to have test methods that more directly modeled the list of situations you identified
Personally I prefer having small, self describing test method names instead of having 3 methods that do everything and making you really dig in there if any one of the tests actually fail. That's why I went the route of building 3 test methods per case I described above:
- If a content stream is provided send that back in the writer & output stream
- If no content stream is provided and no base writer is specified verify the response is serialized with the default writer (XML)
- If no content stream is provided and a base writer is specified serialize with the specified writer
Personally I think this is one of those "beauty is in the eye of the beholder", I kind of prefer the original test but cleanliness and clarity can sometimes be subjective (though "initRawResponseWriter" was a poor naming choice, perhaps "setBaseWriter" would have been better).
You are testing a couple more cases that I wasn't looking for before, which is always a good thing. All the other changes look good, I'm not hung up on any of the test changes.