Buy Access to Course
27.

Functional Testing

Share this awesome video!

|

Keep on Learning!

Functional Testing

Our site is looking cool. But how can we be sure that we haven’t broken anything along the way? Right now, we can’t!

Let’s avoid the future angry phone calls from clients by adding some tests. There are two main types: unit tests and functional tests. Unit tests test individual PHP classes. We’ll save that topic for another screencast. Functional tests are more like a browser that surfs to pages on your site, fills out forms and checks for specific things.

Your First Functional Test

When we generated the EventBundle in the last screencast, it created 2 stub functional tests for us. How nice!

Create a Tests/Controller directory in UserBundle, copy one of the test files and rename it to RegisterControllerTest:

// src/Yoda/UserBundle/Tests/Controller/RegisterControllerTest.php
namespace Yoda\UserBundle\Tests\Controller;

use Symfony\Bundle\FrameworkBundle\Test\WebTestCase;

class RegisterControllerTest extends WebTestCase
{
    public function testRegister()
    {
        $client = static::createClient();
        // ...
    }
}

Rename the method to testRegister:

// src/Yoda/UserBundle/Tests/Controller/RegisterControllerTest.php
// ...

public function testRegister()
{
    $client = static::createClient();
    // ...
}

The idea is that each controller, like RegisterController will have its own test class, like RegisterControllerTest. Then, each action method, like registerAction, will have its own test method, like testRegister. There’s no technical reason you need to organize things like this. The only rule is that you need to start each method with the word “test”.

Using the Client object

That $client variable is like a browser that we can use to surf to pages on our site. Start small by testing that the /register page returns a 200 status code and that the word “Register” appears somewhere:

public function testRegister()
{
    $client = static::createClient();

    $client->request('GET', '/register');
    $response = $client->getResponse();

    $this->assertEquals(200, $response->getStatusCode());
    $this->assertContains('Register', $response->getContent());
}

The assertEquals and assertContains methods come from PHPUnit, the library that will actually run the test.

Installing PHPUnit

To run the test, we need PHPUnit: the de-facto tool for testing. You can install it globally or locally in this project via Composer. For the global option, check out their docs.

Let’s use Composer’s require command and search for phpunit:

php composer.phar require

Choose the phpunit/phpunit result. For a version, I’ll go to packagist.org and find the library. Right now, it looks like the latest version is 4.1.3. I’ll use the constraint ~4.1, which basically means 4.1 or higher.

Tip

Want to know more about the ~ version constraint? Read Next Significant Release on Composer’s website.

This added phpunit/phpunit to the require key in composer.json and it ran the update command in the background to download it.

Tip

Since PHPUnit isn’t actually needed to make our site work (it’s only needed to run the tests), it would be even better to put it in the require-dev key of composer.json. Search for require-dev on this post for more details.

Running the Tests

We now have a bin/phpunit executable, so let’s use it! Pass it a -c app option:

php bin/phpunit -c app

Tip

If you’re on Windows (or a VM running in Windows), the above command won’t work for you (it’ll just spit out some text). Instead, run:

bin\phpunit -c app

This tells PHPUnit to look for a configuration file in the app/ directory. And hey! There’s a phpunit.xml.dist file there already for it to read. This tells phpunit how to bootstrap and where to find our tests.

But we see a few errors. If you look closely, you’ll see that it’s executing the two test files that were generated automatically in EventBundle. Git rid of these troublemakers and try again:

rm src/Yoda/EventBundle/Tests/Controller/*Test.php
php bin/phpunit -c app

Green! PHPUnit runs our test, where we make a request to /register and check the status code and look for the word “Register”.

To see what a failed test looks like, change the test to check for Ackbar instead of Resgister and re-run it:

$this->assertContains('Ackbar', $response->getContent());

It doesn’t find it, but it does print out the page’s content, which we could use to debug. It’s a trap! Change the test back to look for Register:

$this->assertContains('Register', $response->getContent());

Traversing the Dom with the Crawler

When we call the request() function, it returns a Crawler object, which works a lot like the jQuery object in JavaScript. For example, to find the value of the username field, we can search by its id and use the attr function. It should be equal to “Leia”:

public function testRegister()
{
    $client = static::createClient();

    $crawler = $client->request('GET', '/register');
    $response = $client->getResponse();

    $this->assertEquals(200, $response->getStatusCode());
    $this->assertContains('Register', $response->getContent());

    $usernameVal = $crawler
        ->filter('#user_register_username')
        ->attr('value')
    ;
    $this->assertEquals('Leia', $usernameVal);
}

Re-run the test to see the result:

php bin/phpunit -c app

Tip

To see everything about the crawler, check out The DomCrawler Component.