Testing With PHPUnit - Revision history

Demitri at 23:54, 6 February 2014

2014-02-06T23:54:59Z

Demitri: Demitri moved page Test-Driven Development to Testing With PHPUnit: More descriptive and appropriate title; PHPUnit testing can be used even in development that isn't driven by testing.

2014-01-15T23:11:38Z

Demitri moved page Test-Driven Development to Testing With PHPUnit: More descriptive and appropriate title; PHPUnit testing can be used even in development that isn't driven by testing.

Demitri: /* Fixtures and init scripts */

2014-01-15T22:45:13Z

‎Fixtures and init scripts

Demitri: /* Automatically generate fixtures and init scripts: howto */

2013-02-17T23:44:24Z

‎Automatically generate fixtures and init scripts: howto

Demitri: /* What are they? */

2013-02-17T23:39:35Z

‎What are they?

Demitri at 01:45, 1 February 2013

2013-02-01T01:45:58Z

Demitri at 01:43, 1 February 2013

2013-02-01T01:43:42Z

Demitri: /* Functional Testing with Selenium */

2013-02-01T01:39:22Z

‎Functional Testing with Selenium

Demitri: /* Fixtures and init scripts */

2013-02-01T01:29:19Z

‎Fixtures and init scripts

Demitri: /* Preparing a testing database */

2013-02-01T01:29:03Z

‎Preparing a testing database

@@ Line 1: / Line 1: @@
 [[Category:Development]]
-This article covers how to build and use unit and functional tests to develop components and extensions to X2CRM. 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, how they can make testing easier 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:
+This article covers how to build and use unit and functional tests to develop components and extensions to X2Engine. All automated tests in X2Engine 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, how they can make testing easier 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:
 * [http://www.phpunit.de/manual/current/en/automating-tests.html PHPUnit Manual, Ch. 1: Automating Tests]
 * [http://www.phpunit.de/manual/current/en/goals.html PHPUnit Manual, Ch. 2: PHPUnit's Goals]
@@ Line 6: / Line 6: @@
 * [[yiiguide:test.fixture|Defining Fixtures]], [[yiiguide:test.unit|Unit Testing]] and [[yiiguide:test.functional|Functional Testing]] in the Definitive Guide to Yii
-While not all of X2CRM has been built using test-driven development, some tools and structure have been developed to make it easier to use unit and functional testing when developing new features. This article mainly covers them, and is intended as supplemental material (not a replacement) for the existing documentation on test-driven development in Yii using PHPUnit and Selenium.
+While not all of X2Engine has been built using test-driven development, some tools and structure have been developed to make it easier to use unit and functional testing when developing new features. This article mainly covers them, and is intended as supplemental material (not a replacement) for the existing documentation on test-driven development in Yii using PHPUnit and Selenium.
 = Testing in a nutshell =
@@ Line 28: / Line 28: @@
 == Running test cases ==
-Running a test case proceeds as follows: on the server where the testing environment is installed, inside of the <tt>protected/tests</tt> folder, run <pre>phpunit path/to/TestCase.php</pre> or, to run a group of test cases that exist in the same directory: <pre>phpunit directory/</pre> PHPUnit will recursively scan directories for test cases to run. In Yii (and X2CRM), unit tests are stored in <tt>protected/tests/unit</tt> and functional tests in <tt>protected/tests/functional</tt>. For the sake of clarity, in X2CRM, tests are organized into a directory structure that resembles that of the application under the <tt>protected/</tt> folder.
+Running a test case proceeds as follows: on the server where the testing environment is installed, inside of the <tt>protected/tests</tt> folder, run <pre>phpunit path/to/TestCase.php</pre> or, to run a group of test cases that exist in the same directory: <pre>phpunit directory/</pre> PHPUnit will recursively scan directories for test cases to run. In Yii (and X2Engine), unit tests are stored in <tt>protected/tests/unit</tt> and functional tests in <tt>protected/tests/functional</tt>. For the sake of clarity, in X2Engine, tests are organized into a directory structure that resembles that of the application under the <tt>protected/</tt> folder.
 Fortunately, in many shell environments, the previously-run command can be called up by hitting the up arrow on the keyboard. This allows you to quickly re-run an automated test by hitting up and then enter.

← Older revision		Revision as of 22:45, 15 January 2014
Line 95:		Line 95:

	'''Note:''' this will take data from the ''live'' database and not from the testing database.		'''Note:''' this will take data from the ''live'' database and not from the testing database.
		+
		+	== Reference Fixtures ==
		+	If your test case extends X2DbTestCase, you can specify that certain fixtures be loaded at the beginning of a test class only, as "reference" data that will not be changed but will be referenced. This makes running tests faster by skipping re-load of the data, while making fixture data easily accessible as a fixtures property. To do this, declare the static <tt>referenceFixtures</tt> method of your test case such that it returns an array similar to the fixtures property. For example, to load all the user/profile data for reference:
		+	<syntaxhighlight lang="php">
		+	public static function referenceFixtures(){
		+	return array(
		+	'profile' => 'Profile',
		+	'users' => 'User',
		+	);
		+	}
		+	</syntaxhighlight>
		+
		+	== Alternate Fixtures ==
		+	Using <tt>X2FixtureManager</tt> allows you to have more than one fixture per table, and to switch between distinct tests that need different data. You can do this by, in the declaration of a fixture, using a two-element array in place of a string to specify the model or table name. In the array, the first element is assumed to be the name of the active record model or table, whereas the second is a suffix that when appended to the table name and concatenated with ".php" gives the full fixture filename.
		+
		+	For example, if you had a fixture file <tt>x2_users.extra.php</tt>, and wanted to use that file instead of <tt>x2_users.php</tt>, you could use the following fixture definition:
		+	<syntaxhighlight lang="php">
		+	public $fixtures=array(
		+	'users'=>array('User','.extra'),
		+	);
		+	</syntaxhighlight>

	= Functional Testing with Selenium =		= Functional Testing with Selenium =

@@ Line 94: / Line 94: @@
 You will then be prompted to enter some details about the data to be exported. You can also execute the command in one fell swoop; run <tt>./yiic help exportfixture</tt> to see its invocation syntax.
-'''Note:''' that this will take data from the ''live'' database and not from the testing database.
+'''Note:''' this will take data from the ''live'' database and not from the testing database.
 = Functional Testing with Selenium =

@@ Line 60: / Line 60: @@
 '''Initscripts''' allow you to override that behavior; they are similar to fixtures, but define the initial state before loading fixture data.
-As a rule of thumb, the more fixtures you define for a unit test, the more time the test will take to execute, as it means that more database operations will need to take place at the beginning of every test method. If you do not need to reset a particular table in a test case's tests, but need there to be preexisting data to test against, you should create an script for the table(s) instead.
+As a rule of thumb, the more fixtures you define for a unit test, the more time the test will take to execute, as it means that more database operations will need to take place at the beginning of every test method. If you do not need to reset a particular table in a test case's tests, but need there to be preexisting data to test against, you should create an init script for the table(s) instead.
 Note the following comparison between initscripts and fixtures:

@@ Line 1: / Line 1: @@
 [[Category:Development]]
-This article covers how to build and use unit and functional tests to develop components and extensions to X2CRM. 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:
+This article covers how to build and use unit and functional tests to develop components and extensions to X2CRM. 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, how they can make testing easier 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:
 * [http://www.phpunit.de/manual/current/en/automating-tests.html PHPUnit Manual, Ch. 1: Automating Tests]
 * [http://www.phpunit.de/manual/current/en/goals.html PHPUnit Manual, Ch. 2: PHPUnit's Goals]

← Older revision	Revision as of 23:11, 15 January 2014
(No difference)

@@ Line 87: / Line 87: @@
 To understand the behavior of init scripts, one need only look at [[x2propdoc:X2FixtureManager.html#_resetTable|X2FixtureManager::resetTable()]] which, in the case that an array is returned by the init script, inserts the data after truncating the table. Note that additionally, besides defining an initial database state (in its return value, as an array), an init script also may contain arbitrary PHP to be executed at the beginning of a test. This can include such things as filesystem and database schema operations, and thus extend the concept of the initial testing state beyond mere control over ephemeral database contents.
-== How to automatically generate fixtures and init scripts ==
+== Automatically generate fixtures and init scripts: howto ==
 Beginning in version 2.8, fixture scripts can be automatically generated from preexisting database contents using the "exportfixture" Yii console command. To use it:
 # Open a command shell

@@ Line 98: / Line 98: @@
 = Functional Testing with Selenium =
 [[File:PHPUnit.Selenium.png|400px|thumb|right|An advanced PHPUnit/Selenium configuration involving multiple network hosts, operating systems and web browsers. PHPUnit '''(1)''' begins a test by starting browser sessions on a remote host running Selenium RC '''(2)'''. Selenium then commands the web browsers to open the web application in testing mode '''(3)''' and run automated instructions, sending results back to PHPUnit (i.e. whether a test has passed or failed). All logos are &copy; their respective owners.]]
-Selenium provides the means to control and automate browser actions, and hence, to run tests with full browser sessions. Test cases that use Selenium extend <tt>WebTestCase</tt> and are run in the same manner as unit tests, but require that the following environmental conditions are met:
+Selenium provides the means to control and automate browser actions, and hence, to run tests with full web-based sessions and HTTP request data. Test cases that use Selenium extend <tt>WebTestCase</tt> and are run in the same manner as unit tests, but require that the following environmental conditions are met:
 # The <tt>&lt;selenium&gt;</tt> section in the configuration file <tt>protected/tests/phpunit.xml</tt> is set properly. For information on how to configure this, see [http://www.phpunit.de/manual/current/en/appendixes.configuration.html The PHPUnit Manual Appendix C: The XML Configuration File]
 # Selenium RC on all the hosts defined in phpunit.xml can be accessed from the web server on the specified ports (note: if they are behind a firewall, it will be necessary to set up NAT in order to properly use them)

@@ Line 51: / Line 51: @@
 = Fixtures and init scripts =
-When writing tests that extend <tt>CDbTestCase</tt> or <tt>WebTestCase</tt>, it is important to define ''fixtures'' if the test will change any data in the database and, if desired, ''init scripts'' defining how tables should be initialized at the beginning of a test suite and each test.
+When writing tests that extend <tt>CDbTestCase</tt> or <tt>X2WebTestCase</tt>, it is important to define ''fixtures'' if the test will change any data in the database and, if desired, ''init scripts'' defining how tables should be initialized at the beginning of a test suite and each test.
 == What are they? ==

@@ Line 41: / Line 41: @@
 = Preparing a testing database =
 After creating the test database, the following steps can be used to set it up for database testing:
 # Copy the installer files back into the root of the web application: index.php, initialize.php, requirements.php, and initialize_pro.php if on professional edition.
 # Re-run the installer, but enable "Testing Database".
 = Fixtures and init scripts =