How to test a class that generates XML internally - php

Question

Currently I am working to test a class that generates XML based on a value object, sends the XML over HTTP and parses the XML response back into a second value object. I would like to test in this case the generated XML and the parsed value object based on a given XML.
The class looks like:
class MyClient
{
public function send(RequestValues $request)
{
$document = $this->generateMessage($request);
$response = $this->request($document);
return $this->parseResponse($response);
}
protected function generateMessage(RequestValues $request)
{
$document = new DomDocument;
// Do stuff with $request
return $document;
}
public function request(DomDocument $document)
{
$client = $this->getHttpClient();
$client->setRawBody($document->saveXml());
// Configure client
return $client->send();
}
public function parseResponse(Response $response)
{
$parameters = new ResponseValues;
$document = new DomDocument;
$document->loadXml($response->getBody());
// Fill in $parameters
return $parameters;
}
}
I would like to test two things:
Given a certain RequestValues argument, the generated XML must look like $string
Given a certain XML response value (the HTTP client will be mocked), the ResponseValues must be equal to $object
I am now writing a test for #1, but I think I can only achieve this via a callback. The callback however, does not give me quite useful information when the test fails. Only this message:
Failed asserting that DOMDocument Object () is accepted by specified callback.
The test looks like this:
public function testRequestContainsValidXml()
{
$client = $this->getMock('MyClient', array('request'));
$message = '';
$client->expects($this->once())
->method('request')
->with($this->callback(function($object) use ($message) {
return
($object instanceof DomDocument)
&& ($object->saveXml() === $message);
}));
$request = new DirectoryRequest;
$client->send($request);
}
The question is: how can I improve the test such that a normal string comparison is possible? I would love to get phpunit saying "string X is not equal to Y" which eases the debugging enormously.
PS. The complete code of this class is available on GitHub. Naturally, above example is a simplified version. Here's the actual class: https://github.com/juriansluiman/SlmIdealPayment/blob/master/src/SlmIdealPayment/Client/StandardClient.php#L58
PPS. If the code must be changed in order to get it tested, that's not a problem. I'd only want to keep the public API the same (i.e. the call ResponseValues send(RequestValues $request)

Answer 1

You class MyClient suggests that it is a facade. To test a facade in the context of UnitTests it is normally first of all necessary to test all units that are collaborators of that facade.
As you normally mock the collaborators - and not the unit under test - your test setup looks wrong as you're mocking the MyClient unit under test but not it's collaborators.
For example:
You want to test if the MyClient::parseResponse() method returns the expected ResponseValues object. Therefore you would mock the Response as it is a collaborator in this case.
You probably also want to mock the other collaborator (ResponseValues) however you can't as it is a hidden dependency that can not be injected (you could resolve this by injecting a factory to MyClient that can control the creation of such ResponseValues).
So much for testing MyClient::parseResponse(): You would inject the fixture XML via a Response mock and the run your assertions on the return value.
For the case to test if the request contains valid XML (testRequestContainsValidXml()), I don't think it should be done in that complicated form either. Sounds like you have a HTTP client here, you should only test that it works and don't care if it works with XML as well, because if it works, it works with XML as well. The reason why you test for valid XML is not because you want to test the client. So keep that test out of the client unit-tests.
The assertion for the string stuff btw. is:
$this->assertSame($expected, $actual);
Phpunit will show you a nice diff between the strings. Some other programmers / testers were also applying some XML normalization when they compared XML so that the diff is more readable. You might find a Q&A like PHP XML how to output nice format and related useful for that if your XML has no problem to deal with insignificant whitespace.
I hope I could pin-point the problem cases you face with this a little and broaden your view on the problem. I think you come most far with questioning your current mock usage critically, for the examples I give I have fully reduced mocking to providing collaborators, not to do assertions. Asswertions are only done on the unit under test, here the exemplary MyClient.