Testing With PHPUnit

This page covers development using unit and functional tests to develop components and extensions to X2CRM. While not all of X2CRM has been built using test-driven development, some tools and structure have been set up for performing it when developing new features. All automated tests in X2CRM use PHPUnit, and in the case of functional testing, Selenium. To understand more what these tools are, why it is important to know about them and how they will strengthen your design and development methodology (in addition to helping you make your code more stable), the following is recommended reading:

• PHPUnit Manual, Ch. 1: Automating Tests
• PHPUnit Manual, Ch. 2: PHPUnit's Goals
• Selenium: Introduction

Introduction

Tests are organized into PHP classes called *test cases* that are stored within protected/tests/unit (unit tests) or protected/tests/functional (functional tests). Test cases extend one of the following classes:

CTestCase

For ordinary, non-databse unit tests; best for component classes that don't rely on tables or data that is specific to a HTTP request

CDbTestCase

For tests involving communication with a MySQL database, especially if that communication involves a change in any data.

WebTestCase (extends CWebTestCase)

For tests that involve web browser actions.

Running a test case proceeds as follows: on the server where the testing environment is installed, inside of the protected/tests folder, run

phpunit path/to/TestCase.php

or, to run a group of test cases that exist in the same directory:

phpunit directory/

PHPUnit will recursively scan directories for test cases to run.

Anatomy of a test

(in progress)

Installation

For the most up-to-date information on how to install PHPUnit, see Chapter 3: Installing PHPUnit in the official PHPUnit manual. In addition to PHPUnit, you will need each of the following PHPUnit extensions:

• DBUnit
• PHP_Invoker
• PHPUnit_Selenium
• PHPUnit_Story

See the installation guide for more information on how to obtain these extensions.

Setting up a test database

A few very important points to note about tests involving a database connection:

• A different database will be used than the live database
• The contents of each of the test database's tables will be fixed at the beginning of each test using *fixtures*
• All database records generated during tests or through manual interaction will be purged when fixtures for the table in question are used