Ibuildings - Blog - ibuildings.nl

Blog

Ibuildings, blog

Blog

Lorenzo's Blog

Lorenzo Alberton Lorenzo Alberton
Technical Lead Engineer
 Zend PHP5 Certified Engineer
Lorenzo left beautiful Italy for a job as technical lead engineer at our London office, where he has been involved in several development projects. Lorenzo is an active contributor to the PEAR project, and the maintainer of several of PEAR's packages.

Vrijdag, 29 augustus 2008

Zend Framework testing: emulating HTTP calls

Following last month's article by Ian, here's some thoughts on how to test a Zend Framework application.

One of the unit testing best practices suggests to break dependencies, so you can test each component separately.

The first problem that arises when you want to test controllers might be having a tighter control over the HTTP Request and Response objects. Fortunately, ZF already has something that really makes your life easier, i.e. the Zend_Test_PHPUnit_ControllerTestCase class, which has stubs for the Request and Response
objects, and you can easily check headers, return codes, routes, redirects, and even the view itself.

If you haven't tried it yet, do yourself a favor and give it a go.

Once you're familiar with Zend_Test_PHPUnit_ControllerTestCase, you should not have any more problems with testing the controllers. The only caveat is that sometimes, when there are conditional redirects in your actions, it's not easy to track the actual route: if your test assertions fail, trust them and pay closer attention to what the program flow really is.

Let's now see how we can tackle the models.

Typically, this is one of the more problematic areas to test since they almost always have external dependencies (file system, database, mail, etc.). You can "fake" most of these dependencies with some well known tools, like FakeMail or PEAR::Mail_mock, QuerySims, or write your own fake file system (PDF link).

But what if your model is calling a web service?

Remember that what you want to check is the behavior of the model itself, depending on the web service response, and not both the model AND the web service together.

Here's how Dependency Injection comes into play (if you haven't read Ian's article yet, do so now).

The simplest way of detaching the model from the web services is to have an HTTP stub, and use it instead of the "real" HTTP client during tests.

We start by creating the HTTP stub class:

PHP:

<?php

/**
 * Stub for the Zend_Http_Client class to fake REST-style responses
 */
class HttpClientStub extends Zend_Http_Client
{
    /**
     * @var string
     */
    private $_expected;

    /**
     * Send the HTTP request and return an HTTP response object
     
     * @param string $method
     
     * @return Zend_Http_Response
     * @throws Zend_Http_Client_Exception
     */
    public function request($method = null) {
        $headers = array(
            'Date'           => 'Thu, 31 Jul 2008 16:44:38 GMT',
            'Server'         => 'Apache/2.2.8 (EL)',
            'X-powered-by'   => 'PHP/5.2.6',
            'Content-length' => strlen($this->_expected),
            'Connection'     => 'close',
            'Content-type'   => 'text/xml',
        );
        return new Zend_Http_Response(200, $headers, $this->_expected);
    }

    /**
     * Set the expected value for the following request() call
     
     * @param string $value
     
     * @return string
     */
    public function setExpected($value) {
        $this->_expected = $value;
    }
}

?>



Then we add a couple of hooks in our model to inject the HTTP client:

PHP:

<?php

class MyModel
{
    /**
     * @var Zend_Http_Client
     */
    protected static $_httpClient = null;

    /**
     * Set a Zend_Http_Client instance
     * @param Zend_Http_Client $httpClient HTTP client instance
     * @return void
     */
    public static function setHttpClient(Zend_Http_Client $httpClient) {
        self::$_httpClient = $httpClient;
    }

    /**
     * Get a Zend_Http_Client instance
     * @return Zend_Http_Client
     */
    protected static function getHttpClient() {
        if (!self::$_httpClient instanceof Zend_Http_Client) {
            self::$_httpClient = new Zend_Http_Client();
        }
        return self::$_httpClient;
    }
      
    /**
     * An actual method of the model class...
     
     * @param string $param some parameter
     
     * @return string
     */
    public function doSomething($param) {
        $client = self::getHttpClient()->setUri('http://my.web.service/methodname');
        $client->setParameterPost('param', $param);
        $client->setEncType(Zend_Http_Client::ENC_URLENCODED);
        $response = $client->request(Zend_Http_Client::POST);
        
        //...
    }
}

?>



If you don't call setHttpClient() with your object instance, Zend_Http_Client is used by default, so your application will continue working exactly as it used to. The difference is that now you can use another HTTP client (e.g. the stub we created before) in your test cases:

PHP:

<?php

public function testDoSomething()
{       
    $stub = new HttpClientStub();
    // $this->_object is an instance of your MyModel class
    $this->_object->setHttpClient($stub);

    // set the expected response
    $stub->setExpected('<response status="ok"><value>Some Value</value></response>');
    
    // call the model method you want to test
    $res = $this->_object->doSomething('some parameter');
    
    // test the response
    $this->assertEquals('expected result', $res);
}

?>



Of course, you want to repeat the call with different web service responses, so you can cover all the possible conditions of your app. Now, we might want to take it one step further. If your model method calls two or more web services, you clearly need to pass multiple fake responses to the stub HTTP client.

To keep things simple, we can modify the HTTP Stub class and add a queue for the expected responses:

PHP:

<?php

class HttpClientStub extends Zend_Http_Client
{
    /**
     * @var array
     */
    private $_expected = array();

    /**
     * Send the HTTP request and return an HTTP response object
     
     * @param string $method
     * @return Zend_Http_Response
     * @throws Zend_Http_Client_Exception
     */
    public function request($method = null) {
        $expected = array_shift($this->_expected);
        $headers = array(
            'Date'           => 'Thu, 31 Jul 2008 16:44:38 GMT',
            'Server'         => 'Apache/2.2.8 (EL)',
            'X-powered-by'   => 'PHP/5.2.6',
            'Content-length' => strlen($expected),
            'Connection'     => 'close',
            'Content-type'   => 'text/xml',
        );
        return new Zend_Http_Response(200, $headers, $expected);
    }

    /**
     * Set the expected value for the following request() call
     
     * @param string $value
     
     * @return string
     */
    public function setExpected($value) {
        $this->resetExpected();
        $this->addExpected($value);
    }

    /**
     * Set the expected value for the next request() call in the queue
     
     * @param string $value
     
     * @return string
     */
    public function addExpected($value) {
        $this->_expected[] = $value;
    }
    
    /**
     * Reset the expected responses
     
     * @return void
     */
    public function resetExpected() {
        $this->_expected = array();
    }
}

?>



This way, if your doSomething() method contains more than one web service call in its body, you can set the expectations for each one of them:

PHP:

<?php

public function testDoSomething()
{       
    $stub = new HttpClientStub();
    // $this->_object is an instance of your MyModel class
    $this->_object->setHttpClient($stub);

    // set the expected response for each web service call within the doSomething() method
    $stub->setExpected('<response status="ok"><value>Some Value</value></response>');
    $stub->addExpected('<response status="ok"><items><item>Some item</item></items></response>');
    
    // call the model method you want to test
    $res = $this->_object->doSomething('some parameter');
    
    // test the response
    $this->assertEquals('expected result', $res);
}

?>



I hope these notes were useful to some of you. I'd love to hear how you are solving the same problem, so feel free to send me your feedback.
Geplaatst door Lorenzo Alberton in planetphp op 13:53 | Reacties (2) | Trackbacks (0)
Tags voor deze bijdrage: , , , ,
Share

Trackbacks
Trackback-URI voor dit artikel

Geen Trackbacks

Reacties
Geeft reacties weer als (Lineair | Samengevoegd)

It makes my heart warm to know that people are actually reading about and using Zend_Test! I'm really hoping this will revolutionize testing in ZF applications.

Nice article!
#1 Matthew Weier O'Phinney (Homepage) op 29-08-2008 15:44 (Beantwoorden)
I wish dependency injection were used a bit more often, and was a bit more powerful. I think it's useful for more than testing as well.

For example it really bugs me that there's no way to get DOMDocument to create and return a derived class of DOMElement (of my own) when it wants to return a DOMElement. (i.e. "new DOMElement() is hardcoded into the bowels of DOMDocument.)

And it's quite useful when developing to be able to override the mail class to always send mail to a particular address, or direct all emails to a logfile, etc.

This is maybe more relevant to Ian's post, but Google's testing blog has a post on dependency injection from a Java point of view:

http://googletesting.blogspot.com/2008/07/how-to-think-about-new-operator-with.html
#2 Michael S. (Homepage) op 02-09-2008 11:44 (Beantwoorden)

Reactie toevoegen

BBCode opmaak toegestaan
Met sterretjes wordt tekst *vet* gemaakt. Met underscores kan een _woord_ onderstreept worden.
Standaard emoticons zoals :-) en ;-) worden geconverteerd naar plaatjes.
Email adressen worden niet getoond en zijn alleen zichtbaar voor de blogger.

Om het posten door robots tegen te gaan, gelieve de letters die je in het plaatje ziet over te typen. Je commentaar wordt enkel gepost wanneer de letters overeen komen. Je browser dient cookies te ondersteunen (standaard staat dit aan), of je commentaar kan niet geverifieerd worden.
CAPTCHA
 
 
Benelux (wijzig / change)