15-Unit-and-Functional-Testing.txt 57 KB

1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586878889909192939495969798991001011021031041051061071081091101111121131141151161171181191201211221231241251261271281291301311321331341351361371381391401411421431441451461471481491501511521531541551561571581591601611621631641651661671681691701711721731741751761771781791801811821831841851861871881891901911921931941951961971981992002012022032042052062072082092102112122132142152162172182192202212222232242252262272282292302312322332342352362372382392402412422432442452462472482492502512522532542552562572582592602612622632642652662672682692702712722732742752762772782792802812822832842852862872882892902912922932942952962972982993003013023033043053063073083093103113123133143153163173183193203213223233243253263273283293303313323333343353363373383393403413423433443453463473483493503513523533543553563573583593603613623633643653663673683693703713723733743753763773783793803813823833843853863873883893903913923933943953963973983994004014024034044054064074084094104114124134144154164174184194204214224234244254264274284294304314324334344354364374384394404414424434444454464474484494504514524534544554564574584594604614624634644654664674684694704714724734744754764774784794804814824834844854864874884894904914924934944954964974984995005015025035045055065075085095105115125135145155165175185195205215225235245255265275285295305315325335345355365375385395405415425435445455465475485495505515525535545555565575585595605615625635645655665675685695705715725735745755765775785795805815825835845855865875885895905915925935945955965975985996006016026036046056066076086096106116126136146156166176186196206216226236246256266276286296306316326336346356366376386396406416426436446456466476486496506516526536546556566576586596606616626636646656666676686696706716726736746756766776786796806816826836846856866876886896906916926936946956966976986997007017027037047057067077087097107117127137147157167177187197207217227237247257267277287297307317327337347357367377387397407417427437447457467477487497507517527537547557567577587597607617627637647657667677687697707717727737747757767777787797807817827837847857867877887897907917927937947957967977987998008018028038048058068078088098108118128138148158168178188198208218228238248258268278288298308318328338348358368378388398408418428438448458468478488498508518528538548558568578588598608618628638648658668678688698708718728738748758768778788798808818828838848858868878888898908918928938948958968978988999009019029039049059069079089099109119129139149159169179189199209219229239249259269279289299309319329339349359369379389399409419429439449459469479489499509519529539549559569579589599609619629639649659669679689699709719729739749759769779789799809819829839849859869879889899909919929939949959969979989991000100110021003100410051006100710081009101010111012101310141015101610171018101910201021102210231024102510261027102810291030
  1. Chapter 15 - Unit And Functional Testing
  2. ========================================
  3. Automated tests are one of the greatest advances in programming since object orientation. Particularly conducive to developing web applications, they can guarantee the quality of an application even if releases are numerous. Symfony provides a variety of tools for facilitating automated testing, and these are introduced in this chapter.
  4. Automated Tests
  5. ---------------
  6. Any developer with experience developing web applications is well aware of the time it takes to do testing well. Writing test cases, running them, and analyzing the results is a tedious job. In addition, the requirements of web applications tend to change constantly, which leads to an ongoing stream of releases and a continuing need for code refactoring. In this context, new errors are likely to regularly crop up.
  7. That's why automated tests are a suggested, if not required, part of a successful development environment. A set of test cases can guarantee that an application actually does what it is supposed to do. Even if the internals are often reworked, the automated tests prevent accidental regressions. Additionally, they compel developers to write tests in a standardized, rigid format capable of being understood by a testing framework.
  8. Automated tests can sometimes replace developer documentation since they can clearly illustrate what an application is supposed to do. A good test suite shows what output should be expected for a set of test inputs, and that is a good way to explain the purpose of a method.
  9. The symfony framework applies this principle to itself. The internals of the framework are validated by automated tests. These unit and functional tests are not bundled with the PEAR package, but you can check them out from the SVN repository or browse them online at [http://trac.symfony-project.org/browser/branches/1.1/test](http://trac.symfony-project.org/browser/branches/1.1/test).
  10. ### Unit and Functional Tests
  11. Unit tests confirm that a unitary code component provides the correct output for a given input. They validate how functions and methods work in every particular case. Unit tests deal with one case at a time, so for instance a single method may need several unit tests if it works differently in certain situations.
  12. Functional tests validate not a simple input-to-output conversion, but a complete feature. For instance, a cache system can only be validated by a functional test, because it involves more than one step: The first time a page is requested, it is rendered; the second time, it is taken from the cache. So functional tests validate a process and require a scenario. In symfony, you should write functional tests for all your actions.
  13. For the most complex interactions, these two types may fall short. Ajax interactions, for instance, require a web browser to execute JavaScript, so automatically testing them requires a special third-party tool. Furthermore, visual effects can only be validated by a human.
  14. If you have an extensive approach to automated testing, you will probably need to use a combination of all these methods. As a guideline, remember to keep tests simple and readable.
  15. >**NOTE**
  16. >Automated tests work by comparing a result with an expected output. In other words, they evaluate assertions (expressions like `$a == 2`). The value of an assertion is either `true` or `false`, and it determines whether a test passes or fails. The word "assertion" is commonly used when dealing with automated testing techniques.
  17. ### Test-Driven Development
  18. In the test-driven development (TDD) methodology, the tests are written before the code. Writing tests first helps you to focus on the tasks a function should accomplish before actually developing it. It's a good practice that other methodologies, like Extreme Programming (XP), recommend as well. Plus it takes into account the undeniable fact that if you don't write unit tests first, you never write them.
  19. For instance, imagine that you must develop a text-stripping function. The function removes white spaces at the beginning and at the end of the string, replaces nonalphabetical characters by underscores, and transforms all uppercase characters to lowercase ones. In test-driven development, you would first think about all the possible cases and provide an example input and expected output for each, as shown in Table 15-1.
  20. Table 15-1 - A List of Test Cases for a Text-Stripping Function
  21. Input | Expected Output
  22. --------------------- | ---------------------
  23. `" foo "` | `"foo"`
  24. `"foo bar"` | `"foo_bar"`
  25. `"-)foo:..=bar?"` | `"__foo____bar_"`
  26. `"FooBar"` | `"foobar`"
  27. `"Don't foo-bar me!"` | `"don_t_foo_bar_me_"`
  28. You would write the unit tests, run them, and see that they fail. You would then add the necessary code to handle the first test case, run the tests again, see that the first one passes, and go on like that. Eventually, when all the test cases pass, the function is correct.
  29. An application built with a test-driven methodology ends up with roughly as much test code as actual code. As you don't want to spend time debugging your tests cases, keep them simple.
  30. >**NOTE**
  31. >Refactoring a method can create new bugs that didn't use to appear before. That's why it is also a good practice to run all automated tests before deploying a new release of an application in production--this is called regression testing.
  32. ### The Lime Testing Framework
  33. There are many unit test frameworks in the PHP world, with the most well known being PhpUnit and SimpleTest. Symfony has its own, called lime. It is based on the `Test::More` Perl library, and is TAP compliant, which means that the result of tests is displayed as specified in the Test Anything Protocol, designed for better readability of test output.
  34. Lime provides support for unit testing. It is more lightweight than other PHP testing frameworks and has several advantages:
  35. * It launches test files in a sandbox to avoid strange side effects between each test run. Not all testing frameworks guarantee a clean environment for each test.
  36. * Lime tests are very readable, and so is the test output. On compatible systems, lime uses color output in a smart way to distinguish important information.
  37. * Symfony itself uses lime tests for regression testing, so many examples of unit and functional tests can be found in the symfony source code.
  38. * The lime core is validated by unit tests.
  39. * It is written in PHP, and it is fast and well coded. It is contained in a single file, `lime.php`, without any dependence.
  40. The various tests described next use the lime syntax. They work out of the box with any symfony installation.
  41. >**NOTE**
  42. >Unit and functional tests are not supposed to be launched in production. They are developer tools, and as such, they should be run in the developer's computer, not in the host server.
  43. Unit Tests
  44. ----------
  45. Symfony unit tests are simple PHP files ending in `Test.php` and located in the `test/unit/` directory of your application. They follow a simple and readable syntax.
  46. ### What Do Unit Tests Look Like?
  47. Listing 15-1 shows a typical set of unit tests for the `strtolower()` function. It starts by an instantiation of the `lime_test` object (you don't need to worry about the parameters for now). Each unit test is a call to a method of the `lime_test` instance. The last parameter of these methods is always an optional string that serves as the output.
  48. Listing 15-1 - Example Unit Test File, in `test/unit/strtolowerTest.php`
  49. [php]
  50. <?php
  51. include(dirname(__FILE__).'/../bootstrap/unit.php');
  52. require_once(dirname(__FILE__).'/../../lib/strtolower.php');
  53. $t = new lime_test(7, new lime_output_color());
  54. // strtolower()
  55. $t->diag('strtolower()');
  56. $t->isa_ok(strtolower('Foo'), 'string',
  57. 'strtolower() returns a string');
  58. $t->is(strtolower('FOO'), 'foo',
  59. 'strtolower() transforms the input to lowercase');
  60. $t->is(strtolower('foo'), 'foo',
  61. 'strtolower() leaves lowercase characters unchanged');
  62. $t->is(strtolower('12#?@~'), '12#?@~',
  63. 'strtolower() leaves non alphabetical characters unchanged');
  64. $t->is(strtolower('FOO BAR'), 'foo bar',
  65. 'strtolower() leaves blanks alone');
  66. $t->is(strtolower('FoO bAr'), 'foo bar',
  67. 'strtolower() deals with mixed case input');
  68. $t->is(strtolower(''), 'foo',
  69. 'strtolower() transforms empty strings into foo');
  70. Launch the test set from the command line with the `test:unit` task. The command-line output is very explicit, and it helps you localize which tests failed and which passed. See the output of the example test in Listing 15-2.
  71. Listing 15-2 - Launching a Single Unit Test from the Command Line
  72. > php symfony test:unit strtolower
  73. 1..7
  74. # strtolower()
  75. ok 1 - strtolower() returns a string
  76. ok 2 - strtolower() transforms the input to lowercase
  77. ok 3 - strtolower() leaves lowercase characters unchanged
  78. ok 4 - strtolower() leaves non alphabetical characters unchanged
  79. ok 5 - strtolower() leaves blanks alone
  80. ok 6 - strtolower() deals with mixed case input
  81. not ok 7 - strtolower() transforms empty strings into foo
  82. # Failed test (.\batch\test.php at line 21)
  83. # got: ''
  84. # expected: 'foo'
  85. # Looks like you failed 1 tests of 7.
  86. >**TIP**
  87. >The `include` statement at the beginning of Listing 15-1 is optional, but it makes the test file an independent PHP script that you can execute without the symfony command line, by calling `php test/unit/strtolowerTest.php`.
  88. ### Unit Testing Methods
  89. The `lime_test` object comes with a large number of testing methods, as listed in Table 15-2.
  90. Table 15-2 - Methods of the `lime_test` Object for Unit Testing
  91. Method | Description
  92. ------------------------------------------- | -------------------------------------------------------------
  93. `diag($msg)` | Outputs a comment but runs no test
  94. `ok($test, $msg)` | Tests a condition and passes if it is true
  95. `is($value1, $value2, $msg)` | Compares two values and passes if they are equal (`==`)
  96. `isnt($value1, $value2, $msg)` | Compares two values and passes if they are not equal
  97. `like($string, $regexp, $msg)` | Tests a string against a regular expression
  98. `unlike($string, $regexp, $msg)` | Checks that a string doesn't match a regular expression
  99. `cmp_ok($value1, $operator, $value2, $msg)` | Compares two arguments with an operator
  100. `isa_ok($variable, $type, $msg)` | Checks the type of an argument
  101. `isa_ok($object, $class, $msg)` | Checks the class of an object
  102. `can_ok($object, $method, $msg)` | Checks the availability of a method for an object or a class
  103. `is_deeply($array1, $array2, $msg)` | Checks that two arrays have the same values
  104. `include_ok($file, $msg)` | Validates that a file exists and that it is properly included
  105. `fail()` | Always fails--useful for testing exceptions
  106. `pass()` | Always passes--useful for testing exceptions
  107. `skip($msg, $nb_tests)` | Counts as `$nb_tests` tests--useful for conditional tests
  108. `todo()` | Counts as a test--useful for tests yet to be written
  109. The syntax is quite straightforward; notice that most methods take a message as their last parameter. This message is displayed in the output when the test passes. Actually, the best way to learn these methods is to test them, so have a look at Listing 15-3, which uses them all.
  110. Listing 15-3 - Testing Methods of the `lime_test` Object, in `test/unit/exampleTest.php`
  111. [php]
  112. <?php
  113. include(dirname(__FILE__).'/../bootstrap/unit.php');
  114. // Stub objects and functions for test purposes
  115. class myObject
  116. {
  117. public function myMethod()
  118. {
  119. }
  120. }
  121. function throw_an_exception()
  122. {
  123. throw new Exception('exception thrown');
  124. }
  125. // Initialize the test object
  126. $t = new lime_test(16, new lime_output_color());
  127. $t->diag('hello world');
  128. $t->ok(1 == '1', 'the equal operator ignores type');
  129. $t->is(1, '1', 'a string is converted to a number for comparison');
  130. $t->isnt(0, 1, 'zero and one are not equal');
  131. $t->like('test01', '/test\d+/', 'test01 follows the test numbering pattern');
  132. $t->unlike('tests01', '/test\d+/', 'tests01 does not follow the pattern');
  133. $t->cmp_ok(1, '<', 2, 'one is inferior to two');
  134. $t->cmp_ok(1, '!==', true, 'one and true are not identical');
  135. $t->isa_ok('foobar', 'string', '\'foobar\' is a string');
  136. $t->isa_ok(new myObject(), 'myObject', 'new creates object of the right class');
  137. $t->can_ok(new myObject(), 'myMethod', 'objects of class myObject do have a myMethod method');
  138. $array1 = array(1, 2, array(1 => 'foo', 'a' => '4'));
  139. $t->is_deeply($array1, array(1, 2, array(1 => 'foo', 'a' => '4')),
  140. 'the first and the second array are the same');
  141. $t->include_ok('./fooBar.php', 'the fooBar.php file was properly included');
  142. try
  143. {
  144. throw_an_exception();
  145. $t->fail('no code should be executed after throwing an exception');
  146. }
  147. catch (Exception $e)
  148. {
  149. $t->pass('exception caught successfully');
  150. }
  151. if (!isset($foobar))
  152. {
  153. $t->skip('skipping one test to keep the test count exact in the condition', 1);
  154. }
  155. else
  156. {
  157. $t->ok($foobar, 'foobar');
  158. }
  159. $t->todo('one test left to do');
  160. You will find a lot of other examples of the usage of these methods in the symfony unit tests.
  161. >**TIP**
  162. >You may wonder why you would use `is()` as opposed to `ok()` here. The error message output by `is()` is much more explicit; it shows both members of the test, while `ok()` just says that the condition failed.
  163. ### Testing Parameters
  164. The initialization of the `lime_test` object takes as its first parameter the number of tests that should be executed. If the number of tests finally executed differs from this number, the lime output warns you about it. For instance, the test set of Listing 15-3 outputs as Listing 15-4. The initialization stipulated that 16 tests were to run, but only 15 actually took place, so the output indicates this.
  165. Listing 15-4 - The Count of Test Run Helps You to Plan Tests
  166. > php symfony test:unit example
  167. 1..16
  168. # hello world
  169. ok 1 - the equal operator ignores type
  170. ok 2 - a string is converted to a number for comparison
  171. ok 3 - zero and one are not equal
  172. ok 4 - test01 follows the test numbering pattern
  173. ok 5 - tests01 does not follow the pattern
  174. ok 6 - one is inferior to two
  175. ok 7 - one and true are not identical
  176. ok 8 - 'foobar' is a string
  177. ok 9 - new creates object of the right class
  178. ok 10 - objects of class myObject do have a myMethod method
  179. ok 11 - the first and the second array are the same
  180. not ok 12 - the fooBar.php file was properly included
  181. # Failed test (.\test\unit\testTest.php at line 27)
  182. # Tried to include './fooBar.php'
  183. ok 13 - exception catched successfully
  184. ok 14 # SKIP skipping one test to keep the test count exact in the condition
  185. ok 15 # TODO one test left to do
  186. # Looks like you planned 16 tests but only ran 15.
  187. # Looks like you failed 1 tests of 16.
  188. The `diag()` method doesn't count as a test. Use it to show comments, so that your test output stays organized and legible. On the other hand, the `todo()` and `skip()` methods count as actual tests. A `pass()`/`fail()` combination inside a `try`/`catch` block counts as a single test.
  189. A well-planned test strategy must contain an expected number of tests. You will find it very useful to validate your own test files--especially in complex cases where tests are run inside conditions or exceptions. And if the test fails at some point, you will see it quickly because the final number of run tests won't match the number given during initialization.
  190. The second parameter of the constructor is an output object extending the `lime_output` class. Most of the time, as tests are meant to be run through a CLI, the output is a lime_output_color object, taking advantage of bash coloring when available.
  191. ### The test:unit Task
  192. The `test:unit` task, which launches unit tests from the command line, expects either a list of test names or a file pattern. See Listing 15-5 for details.
  193. Listing 15-5 - Launching Unit Tests
  194. // Test directory structure
  195. test/
  196. unit/
  197. myFunctionTest.php
  198. mySecondFunctionTest.php
  199. foo/
  200. barTest.php
  201. > php symfony test:unit myFunction ## Run myFunctionTest.php
  202. > php symfony test:unit myFunction mySecondFunction ## Run both tests
  203. > php symfony test:unit 'foo/*' ## Run barTest.php
  204. > php symfony test:unit '*' ## Run all tests (recursive)
  205. ### Stubs, Fixtures, and Autoloading
  206. In a unit test, the autoloading feature is not active by default. Each class that you use in a test must be either defined in the test file or required as an external dependency. That's why many test files start with a group of `include` lines, as Listing 15-6 demonstrates.
  207. Listing 15-6 - Including Classes in Unit Tests
  208. [php]
  209. <?php
  210. include(dirname(__FILE__).'/../bootstrap/unit.php');
  211. require_once($sf_symfony_lib_dir.'/util/sfToolkit.class.php');
  212. $t = new lime_test(7, new lime_output_color());
  213. // isPathAbsolute()
  214. $t->diag('isPathAbsolute()');
  215. $t->is(sfToolkit::isPathAbsolute('/test'), true,
  216. 'isPathAbsolute() returns true if path is absolute');
  217. $t->is(sfToolkit::isPathAbsolute('\\test'), true,
  218. 'isPathAbsolute() returns true if path is absolute');
  219. $t->is(sfToolkit::isPathAbsolute('C:\\test'), true,
  220. 'isPathAbsolute() returns true if path is absolute');
  221. $t->is(sfToolkit::isPathAbsolute('d:/test'), true,
  222. 'isPathAbsolute() returns true if path is absolute');
  223. $t->is(sfToolkit::isPathAbsolute('test'), false,
  224. 'isPathAbsolute() returns false if path is relative');
  225. $t->is(sfToolkit::isPathAbsolute('../test'), false,
  226. 'isPathAbsolute() returns false if path is relative');
  227. $t->is(sfToolkit::isPathAbsolute('..\\test'), false,
  228. 'isPathAbsolute() returns false if path is relative');
  229. In unit tests, you need to instantiate not only the object you're testing, but also the object it depends upon. Since unit tests must remain unitary, depending on other classes may make more than one test fail if one class is broken. In addition, setting up real objects can be expensive, both in terms of lines of code and execution time. Keep in mind that speed is crucial in unit testing because developers quickly tire of a slow process.
  230. Whenever you start including many scripts for a unit test, you may need a simple autoloading system. For this purpose, the sfSimpleAutoload class (which must be manually included) provides an addDirectory() method which expects an absolute path as parameter and that can be called several times in case you need to include several directories on the search path. All the classes located under this path will be autoloaded. For instance, if you want to have all the classes located under `$sf_symfony_lib_dir/util/` autoloaded, start your unit test script as follows:
  231. [php]
  232. require_once($sf_symfony_lib_dir.'/autoload/sfSimpleAutoload.class.php');
  233. $autoload = sfSimpleAutoload::getInstance();
  234. $autoload->addDirectory($sf_symfony_lib_dir.'/util');
  235. $autoload->register();
  236. Another good workaround for the autoloading issues is the use of stubs. A stub is an alternative implementation of a class where the real methods are replaced with simple canned data. It mimics the behavior of the real class, but without its cost. A good example of stubs is a database connection or a web service interface. In Listing 15-7, the unit tests for a mapping API rely on a `WebService` class. Instead of calling the real `fetch()` method of the actual web service class, the test uses a stub that returns test data.
  237. Listing 15-7 - Using Stubs in Unit Tests
  238. [php]
  239. require_once(dirname(__FILE__).'/../../lib/WebService.class.php');
  240. require_once(dirname(__FILE__).'/../../lib/MapAPI.class.php');
  241. class testWebService extends WebService
  242. {
  243. public static function fetch()
  244. {
  245. return file_get_contents(dirname(__FILE__).'/fixtures/data/fake_web_service.xml');
  246. }
  247. }
  248. $myMap = new MapAPI();
  249. $t = new lime_test(1, new lime_output_color());
  250. $t->is($myMap->getMapSize(testWebService::fetch(), 100));
  251. The test data can be more complex than a string or a call to a method. Complex test data is often referred to as fixtures. For coding clarity, it is often better to keep fixtures in separate files, especially if they are used by more than one unit test file. Also, don't forget that symfony can easily transform a YAML file into an array with the `sfYAML::load()` method. This means that instead of writing long PHP arrays, you can write your test data in a YAML file, as in Listing 15-8.
  252. Listing 15-8 - Using Fixture Files in Unit Tests
  253. [php]
  254. // In fixtures.yml:
  255. -
  256. input: '/test'
  257. output: true
  258. comment: isPathAbsolute() returns true if path is absolute
  259. -
  260. input: '\\test'
  261. output: true
  262. comment: isPathAbsolute() returns true if path is absolute
  263. -
  264. input: 'C:\\test'
  265. output: true
  266. comment: isPathAbsolute() returns true if path is absolute
  267. -
  268. input: 'd:/test'
  269. output: true
  270. comment: isPathAbsolute() returns true if path is absolute
  271. -
  272. input: 'test'
  273. output: false
  274. comment: isPathAbsolute() returns false if path is relative
  275. -
  276. input: '../test'
  277. output: false
  278. comment: isPathAbsolute() returns false if path is relative
  279. -
  280. input: '..\\test'
  281. output: false
  282. comment: isPathAbsolute() returns false if path is relative
  283. // In testTest.php
  284. <?php
  285. include(dirname(__FILE__).'/../bootstrap/unit.php');
  286. require_once($sf_symfony_lib_dir.'/util/sfToolkit.class.php');
  287. require_once($sf_symfony_lib_dir.'/yaml/sfYaml.class.php');
  288. $testCases = sfYaml::load(dirname(__FILE__).'/fixtures.yml');
  289. $t = new lime_test(count($testCases), new lime_output_color());
  290. // isPathAbsolute()
  291. $t->diag('isPathAbsolute()');
  292. foreach ($testCases as $case)
  293. {
  294. $t->is(sfToolkit::isPathAbsolute($case['input']), $case['output'],$case['comment']);
  295. }
  296. ### Unit testing Propel classes
  297. Testing Propel classes is a bit more involving as the generated Propel objects rely on a long cascade of classes. Moreover, you need to provide a valid database connection to Propel and you also need to feed the database with some test data.
  298. Thankfully, it is quite easy as symfony already provides everything you need:
  299. * To get autoloading, you need to initialize a configuration object
  300. * To get a database connection, you need to initialize the `sfDatabaseManager` class
  301. * To load some test data, you can use the `sfPropelData` class
  302. A typical Propel test file is shown in Listing 15-9.
  303. Listing 15-9 - Testing Propel classes
  304. [php]
  305. <?php
  306. include(dirname(__FILE__).'/../bootstrap/unit.php');
  307. new sfDatabaseManager(ProjectConfiguration::getApplicationConfiguration('frontend', 'test', true));
  308. $loader = new sfPropelData();
  309. $loader->loadData(sfConfig::get('sf_data_dir').'/fixtures');
  310. $t = new lime_test(1, new lime_output_color());
  311. // begin testing your model class
  312. $t->diag('->retrieveByUsername()');
  313. $user = UserPeer::retrieveByUsername('fabien');
  314. $t->is($user->getLastName(), 'Potencier', '->retrieveByUsername() returns the User for the given username');
  315. Functional Tests
  316. ----------------
  317. Functional tests validate parts of your applications. They simulate a browsing session, make requests, and check elements in the response, just like you would do manually to validate that an action does what it's supposed to do. In functional tests, you run a scenario corresponding to a use case.
  318. ### What Do Functional Tests Look Like?
  319. You could run your functional tests with a text browser and a lot of regular expression assertions, but that would be a great waste of time. Symfony provides a special object, called `sfBrowser`, which acts like a browser connected to a symfony application without actually needing a server--and without the slowdown of the HTTP transport. It gives access to the core objects of each request (the request, session, context, and response objects). Symfony also provides an extension of this class called `sfTestBrowser`, designed especially for functional tests, which has all the abilities of the `sfBrowser` object plus some smart assert methods.
  320. A functional test traditionally starts with an initialization of a test browser object. This object makes a request to an action and verifies that some elements are present in the response.
  321. For example, every time you generate a module skeleton with the `generate:module` or the `propel:generate-crud` tasks, symfony creates a simple functional test for this module. The test makes a request to the default action of the module and checks the response status code, the module and action calculated by the routing system, and the presence of a certain sentence in the response content. For a `foobar` module, the generated `foobarActionsTest.php` file looks like Listing 15-9.
  322. Listing 15-9 - Default Functional Test for a New Module, in `tests/functional/frontend/foobarActionsTest.php`
  323. [php]
  324. <?php
  325. include(dirname(__FILE__).'/../../bootstrap/functional.php');
  326. // Create a new test browser
  327. $browser = new sfTestBrowser();
  328. $browser->
  329. get('/foobar/index')->
  330. isStatusCode(200)->
  331. isRequestParameter('module', 'foobar')->
  332. isRequestParameter('action', 'index')->
  333. checkResponseElement('body', '!/This is a temporary page/')
  334. ;
  335. >**TIP**
  336. >The browser methods return an `sfTestBrowser` object, so you can chain the method calls for more readability of your test files. This is called a fluid interface to the object, because nothing stops the flow of method calls.
  337. A functional test can contain several requests and more complex assertions; you will soon discover all the possibilities in the upcoming sections.
  338. To launch a functional test, use the `test:functional` task with the symfony command line, as shown in Listing 15-10. This task expects an application name and a test name (omit the `Test.php` suffix).
  339. Listing 15-10 - Launching a Single Functional Test from the Command Line
  340. > php symfony test:functional frontend foobarActions
  341. # get /comment/index
  342. ok 1 - status code is 200
  343. ok 2 - request parameter module is foobar
  344. ok 3 - request parameter action is index
  345. not ok 4 - response selector body does not match regex /This is a temporary page/
  346. # Looks like you failed 1 tests of 4.
  347. 1..4
  348. The generated functional tests for a new module don't pass by default. This is because in a newly created module, the `index` action forwards to a congratulations page (included in the symfony `default` module), which contains the sentence "This is a temporary page". As long as you don't modify the `index` action, the tests for this module will fail, and this guarantees that you cannot pass all tests with an unfinished module.
  349. >**NOTE**
  350. >In functional tests, the autoloading is activated, so you don't have to include the files by hand.
  351. ### Browsing with the sfTestBrowser Object
  352. The test browser is capable of making GET and POST requests. In both cases, use a real URI as parameter. Listing 15-11 shows how to write calls to the `sfTestBrowser` object to simulate requests.
  353. Listing 15-11 - Simulating Requests with the `sfTestBrowser` Object
  354. [php]
  355. include(dirname(__FILE__).'/../../bootstrap/functional.php');
  356. // Create a new test browser
  357. $b = new sfTestBrowser();
  358. $b->get('/foobar/show/id/1'); // GET request
  359. $b->post('/foobar/show', array('id' => 1)); // POST request
  360. // The get() and post() methods are shortcuts to the call() method
  361. $b->call('/foobar/show/id/1', 'get');
  362. $b->call('/foobar/show', 'post', array('id' => 1));
  363. // The call() method can simulate requests with any method
  364. $b->call('/foobar/show/id/1', 'head');
  365. $b->call('/foobar/add/id/1', 'put');
  366. $b->call('/foobar/delete/id/1', 'delete');
  367. A typical browsing session contains not only requests to specific actions, but also clicks on links and on browser buttons. As shown in Listing 15-12, the `sfTestBrowser` object is also capable of simulating those.
  368. Listing 15-12 - Simulating Navigation with the `sfTestBrowser` Object
  369. [php]
  370. $b->get('/'); // Request to the home page
  371. $b->get('/foobar/show/id/1');
  372. $b->back(); // Back to one page in history
  373. $b->forward(); // Forward one page in history
  374. $b->reload(); // Reload current page
  375. $b->click('go'); // Look for a 'go' link or button and click it
  376. The test browser handles a stack of calls, so the `back()` and `forward()` methods work as they do on a real browser.
  377. >**TIP**
  378. >The test browser has its own mechanisms to manage sessions (`sfTestStorage`) and cookies.
  379. Among the interactions that most need to be tested, those associated with forms probably rank first. To simulate form input and submission, you have three choices. You can either make a POST request with the parameters you wish to send, call `click()` with the form parameters as an array, or fill in the fields one by one and click the submit button. They all result in the same POST request anyhow. Listing 15-13 shows an example.
  380. Listing 15-13 - Simulating Form Input with the `sfTestBrowser` Object
  381. [php]
  382. // Example template in modules/foobar/templates/editSuccess.php
  383. <?php echo form_tag('foobar/update') ?>
  384. <?php echo input_hidden_tag('id', $sf_params->get('id')) ?>
  385. <?php echo input_tag('name', 'foo') ?>
  386. <?php echo submit_tag('go') ?>
  387. <?php echo textarea('text1', 'foo') ?>
  388. <?php echo textarea('text2', 'bar') ?>
  389. </form>
  390. // Example functional test for this form
  391. $b = new sfTestBrowser();
  392. $b->get('/foobar/edit/id/1');
  393. // Option 1: POST request
  394. $b->post('/foobar/update', array('id' => 1, 'name' => 'dummy', 'commit' => 'go'));
  395. // Option 2: Click the submit button with parameters
  396. $b->click('go', array('name' => 'dummy'));
  397. // Option 3: Enter the form values field by field name then click the submit button
  398. $b->setField('name', 'dummy')->
  399. click('go');
  400. >**NOTE**
  401. >With the second and third options, the default form values are automatically included in the form submission, and the form target doesn't need to be specified.
  402. When an action finishes by a `redirect()`, the test browser doesn't automatically follow the redirection; you must follow it manually with `followRedirect()`, as demonstrated in Listing 15-14.
  403. Listing 15-14 - The Test Browser Doesn't Automatically Follow Redirects
  404. [php]
  405. // Example action in modules/foobar/actions/actions.class.php
  406. public function executeUpdate($request)
  407. {
  408. // ...
  409. $this->redirect('foobar/show?id='.$request->getParameter('id'));
  410. }
  411. // Example functional test for this action
  412. $b = new sfTestBrowser();
  413. $b->get('/foobar/edit?id=1')->
  414. click('go', array('name' => 'dummy'))->
  415. isRedirected()-> // Check that request is redirected
  416. followRedirect(); // Manually follow the redirection
  417. There is one last method you should know about that is useful for browsing: `restart()` reinitializes the browsing history, session, and cookies--as if you restarted your browser.
  418. Once it has made a first request, the `sfTestBrowser` object can give access to the request, context, and response objects. It means that you can check a lot of things, ranging from the text content to the response headers, the request parameters, and configuration:
  419. [php]
  420. $request = $b->getRequest();
  421. $context = $b->getContext();
  422. $response = $b->getResponse();
  423. >**SIDEBAR**
  424. >The sfBrowser object
  425. >
  426. >All the browsing methods described in Listings 15-10 to 15-13 are also available out of the testing scope, throughout the `sfBrowser` object. You can call it as follows:
  427. >
  428. > [php]
  429. > // Create a new browser
  430. > $b = new sfBrowser();
  431. > $b->get('/foobar/show/id/1')->
  432. > setField('name', 'dummy')->
  433. > click('go');
  434. > $content = $b->getResponse()->getContent();
  435. > // ...
  436. >
  437. >The `sfBrowser` object is a very useful tool for batch scripts, for instance, if you want to browse a list of pages to generate a cached version for each (refer to Chapter 18 for a detailed example).
  438. ### Using Assertions
  439. Due to the `sfTestBrowser` object having access to the response and other components of the request, you can do tests on these components. You could create a new `lime_test` object for that purpose, but fortunately `sfTestBrowser` proposes a `test()` method that returns a `lime_test` object where you can call the unit assertion methods described previously. Check Listing 15-15 to see how to do assertions via `sfTestBrowser`.
  440. Listing 15-15 - The Test Browser Provides Testing Abilities with the `test()` Method
  441. [php]
  442. $b = new sfTestBrowser();
  443. $b->get('/foobar/edit/id/1');
  444. $request = $b->getRequest();
  445. $context = $b->getContext();
  446. $response = $b->getResponse();
  447. // Get access to the lime_test methods via the test() method
  448. $b->test()->is($request->getParameter('id'), 1);
  449. $b->test()->is($response->getStatuscode(), 200);
  450. $b->test()->is($response->getHttpHeader('content-type'), 'text/html;charset=utf-8');
  451. $b->test()->like($response->getContent(), '/edit/');
  452. >**NOTE**
  453. >The `getResponse()`, `getContext()`, `getRequest()`, and `test()` methods don't return an `sfTestBrowser` object, therefore you can't chain other `sfTestBrowser` method calls after them.
  454. You can check incoming and outgoing cookies easily via the request and response objects, as shown in Listing 15-16.
  455. Listing 15-16 - Testing Cookies with `sfTestBrowser`
  456. [php]
  457. $b->test()->is($request->getCookie('foo'), 'bar'); // Incoming cookie
  458. $cookies = $response->getCookies();
  459. $b->test()->is($cookies['foo'], 'foo=bar'); // Outgoing cookie
  460. Using the `test()` method to test the request elements ends up in long lines. Fortunately, `sfTestbrowser` contains a bunch of proxy methods that help you keep your functional tests readable and short--in addition to returning an `sfTestBrowser` object themselves. For instance, you can rewrite Listing 15-15 in a faster way, as shown in Listing 15-17.
  461. Listing 15-17 - Testing Directly with `sfTestBrowser`
  462. [php]
  463. $b = new sfTestBrowser();
  464. $b->get('/foobar/edit/id/1')->
  465. isRequestParameter('id', 1)->
  466. isStatusCode()->
  467. isResponseHeader('content-type', 'text/html; charset=utf-8')->
  468. responseContains('edit');
  469. The status 200 is the default value of the parameter expected by `isStatusCode()`, so you can call it without any argument to test a successful response.
  470. One more advantage of proxy methods is that you don't need to specify an output text as you would with a `lime_test` method. The messages are generated automatically by the proxy methods, and the test output is clear and readable.
  471. # get /foobar/edit/id/1
  472. ok 1 - request parameter "id" is "1"
  473. ok 2 - status code is "200"
  474. ok 3 - response header "content-type" is "text/html"
  475. ok 4 - response contains "edit"
  476. 1..4
  477. In practice, the proxy methods of Listing 15-17 cover most of the usual tests, so you will seldom use the `test()` method on an `sfTestBrowser` object.
  478. Listing 15-14 showed that `sfTestBrowser` doesn't automatically follow redirections. This has one advantage: You can test a redirection. For instance, Listing 15-18 shows how to test the response of Listing 15-14.
  479. Listing 15-18 - Testing Redirections with `sfTestBrowser`
  480. [php]
  481. $b = new sfTestBrowser();
  482. $b->
  483. get('/foobar/edit/id/1')->
  484. click('go', array('name' => 'dummy'))->
  485. isStatusCode(200)->
  486. isRequestParameter('module', 'foobar')->
  487. isRequestParameter('action', 'update')->
  488. isRedirected()-> // Check that the response is a redirect
  489. followRedirect()-> // Manually follow the redirection
  490. isStatusCode(200)->
  491. isRequestParameter('module', 'foobar')->
  492. isRequestParameter('action', 'show');
  493. ### Using CSS Selectors
  494. Many of the functional tests validate that a page is correct by checking for the presence of text in the content. With the help of regular expressions in the `responseContains()` method, you can check displayed text, a tag's attributes, or values. But as soon as you want to check something deeply buried in the response DOM, regular expressions are not ideal.
  495. That's why the `sfTestBrowser` object supports a `getResponseDom()` method. It returns a libXML2 DOM object, much easier to parse and test than a flat text. Refer to Listing 15-19 for an example of using this method.
  496. Listing 15-19 - The Test Browser Gives Access to the Response Content As a DOM Object
  497. [php]
  498. $b = new sfTestBrowser();
  499. $b->get('/foobar/edit/id/1');
  500. $dom = $b->getResponseDom();
  501. $b->test()->is($dom->getElementsByTagName('input')->item(1)->getAttribute('type'),'text');
  502. But parsing an HTML document with the PHP DOM methods is still not fast and easy enough. If you are familiar with the CSS selectors, you know that they are an even more powerful way to retrieve elements from an HTML document. Symfony provides a tool class called `sfDomCssSelector` that expects a DOM document as construction parameter. It has a getTexts() method that returns an array of strings according to a CSS selector, and a getElements() method that returns an array of DOM elements. See an example in Listing 15-20.
  503. Listing 15-20 - The Test Browser Gives Access to the Response Content As an `sfDomCssSelector` Object
  504. [php]
  505. $b = new sfTestBrowser();
  506. $b->get('/foobar/edit/id/1');
  507. $c = new sfDomCssSelector($b->getResponseDom())
  508. $b->test()->is($c->getTexts('form input[type="hidden"][value="1"]'), array('');
  509. $b->test()->is($c->getTexts('form textarea[name="text1"]'), array('foo'));
  510. $b->test()->is($c->getTexts('form input[type="submit"]'), array(''));
  511. In its constant pursuit for brevity and clarity, symfony provides a shortcut for this: the `checkResponseElement()` proxy method. This method makes Listing 15-20 look like Listing 15-21.
  512. Listing 15-21 - The Test Browser Gives Access to the Elements of the Response by CSS Selectors
  513. [php]
  514. $b = new sfTestBrowser();
  515. $b->get('/foobar/edit/id/1')->
  516. checkResponseElement('form input[type="hidden"][value="1"]', true)->
  517. checkResponseElement('form textarea[name="text1"]', 'foo')->
  518. checkResponseElement('form input[type="submit"]', 1);
  519. The behavior of the `checkResponseElement()` method depends on the type of the second argument that it receives:
  520. * If it is a Boolean, it checks that an element matching the CSS selector exists.
  521. * If it is an integer, it checks that the CSS selector returns this number of results.
  522. * If it is a regular expression, it checks that the first element found by the CSS selector matches it.
  523. * If it is a regular expression preceded by `!`, it checks that the first element doesn't match the pattern.
  524. * For other cases, it compares the first element found by the CSS selector with the second argument as a string.
  525. The method accepts a third optional parameter, in the shape of an associative array. It allows you to have the test performed not on the first element returned by the selector (if it returns several), but on another element at a certain position, as shown in Listing 15-22.
  526. Listing 15-22 - Using the Position Option to Match an Element at a Certain Position
  527. [php]
  528. $b = new sfTestBrowser();
  529. $b->get('/foobar/edit?id=1')->
  530. checkResponseElement('form textarea', 'foo')->
  531. checkResponseElement('form textarea', 'bar', array('position' => 1));
  532. The options array can also be used to perform two tests at the same time. You can test that there is an element matching a selector and how many there are, as demonstrated in Listing 15-23.
  533. Listing 15-23 - Using the Count Option to Count the Number of Matches
  534. [php]
  535. $b = new sfTestBrowser();
  536. $b->get('/foobar/edit?id=1')->
  537. checkResponseElement('form input', true, array('count' => 3));
  538. The selector tool is very powerful. It accepts most of the CSS 3 selectors, and you can use it for complex queries such as those of Listing 15-24.
  539. Listing 15-24 - Example of Complex CSS Selectors Accepted by `checkResponseElement()`
  540. [php]
  541. $b->checkResponseElement('ul#list li a[href]', 'click me');
  542. $b->checkResponseElement('ul > li', 'click me');
  543. $b->checkResponseElement('ul + li', 'click me');
  544. $b->checkResponseElement('h1, h2', 'click me');
  545. $b->checkResponseElement('a[class$="foo"][href*="bar.html"]', 'my link');
  546. $b->checkResponseElement('p:last ul:nth-child(2) li:contains("Some text")');
  547. ### Testing for errors
  548. Sometimes, your actions or your model throw exceptions on purpose (for example to display a 404 page). Even if you can use a CSS selector to check for a specific error message in the generated HTML code, it's better to use the `throwsException` method to check that an exception has been thrown as show in Listing 15-25.
  549. Listing 15-25 - Testing for Exceptions
  550. [php]
  551. $b = new sfTestBrowser();
  552. $b->
  553. get('/foobar/edit/id/1')->
  554. click('go', array('name' => 'dummy'))->
  555. isStatusCode(200)->
  556. isRequestParameter('module', 'foobar')->
  557. isRequestParameter('action', 'update')->
  558. throwsException()-> // Checks that the last request threw an exception
  559. throwsException('RuntimeException')-> // Checks the class of the exception
  560. throwsException(null, '/error/'); // Checks that the content of the exception message matches the regular expression
  561. ### Working in the Test Environment
  562. The `sfTestBrowser` object uses a special front controller, set to the `test` environment. The default configuration for this environment appears in Listing 15-26.
  563. Listing 15-26 - Default Test Environment Configuration, in `frontend/config/settings.yml`
  564. test:
  565. .settings:
  566. error_reporting: <?php echo (E_ALL | E_STRICT & ~E_NOTICE)."\n" ?>
  567. cache: off
  568. web_debug: off
  569. no_script_name: off
  570. etag: off
  571. The cache and the web debug toolbar are set to `off` in this environment. However, the code execution still leaves traces in a log file, distinct from the `dev` and `prod` log files, so that you can check it independently (`myproject/log/frontend_test.log`). In this environment, the exceptions don't stop the execution of the scripts--so that you can run an entire set of tests even if one fails. You can have specific database connection settings, for instance, to use another database with test data in it.
  572. Before using the `sfTestBrowser` object, you have to initialize it. If you need to, you can specify a hostname for the application and an IP address for the client--that is, if your application makes controls over these two parameters. Listing 15-27 demonstrates how to do this.
  573. Listing 15-27 - Setting Up the Test Browser with Hostname and IP
  574. [php]
  575. $b = new sfTestBrowser('myapp.example.com', '123.456.789.123');
  576. ### The test:functional Task
  577. The `test:functional` task can run one or more functional tests, depending on the number of arguments received. The rules look much like the ones of the `test:unit` task, except that the functional test task always expects an application as first argument, as shown in Listing 15-28.
  578. Listing 15-28 - Functional Test Task Syntax
  579. // Test directory structure
  580. test/
  581. functional/
  582. frontend/
  583. myModuleActionsTest.php
  584. myScenarioTest.php
  585. backend/
  586. myOtherScenarioTest.php
  587. ## Run all functional tests for one application, recursively
  588. > php symfony test:functional frontend
  589. ## Run one given functional test
  590. > php symfony test:functional frontend myScenario
  591. ## Run several tests based on a pattern
  592. > php symfony test:functional frontend my*
  593. Test Naming Practices
  594. ---------------------
  595. This section lists a few good practices to keep your tests organized and easy to maintain. The tips concern file organization, unit tests, and functional tests.
  596. As for the file structure, you should name the unit test files using the class they are supposed to test, and name the functional test files using the module or the scenario they are supposed to test. See Listing 15-29 for an example. Your `test/` directory will soon contain a lot of files, and finding a test might prove difficult in the long run if you don't follow these guidelines.
  597. Listing 15-29 - Example File Naming Practice
  598. test/
  599. unit/
  600. myFunctionTest.php
  601. mySecondFunctionTest.php
  602. foo/
  603. barTest.php
  604. functional/
  605. frontend/
  606. myModuleActionsTest.php
  607. myScenarioTest.php
  608. backend/
  609. myOtherScenarioTest.php
  610. For unit tests, a good practice is to group the tests by function or method, and start each test group with a `diag()` call. The messages of each unit test should contain the name of the function or method tested, followed by a verb and a property, so that the test output looks like a sentence describing a property of the object. Listing 15-30 shows an example.
  611. Listing 15-30 - Example Unit Test Naming Practice
  612. [php]
  613. // srttolower()
  614. $t->diag('strtolower()');
  615. $t->isa_ok(strtolower('Foo'), 'string', 'strtolower() returns a string');
  616. $t->is(strtolower('FOO'), 'foo', 'strtolower() transforms the input to lowercase');
  617. # strtolower()
  618. ok 1 - strtolower() returns a string
  619. ok 2 - strtolower() transforms the input to lowercase
  620. Functional tests should be grouped by page and start with a request. Listing 15-31 illustrates this practice.
  621. Listing 15-31 - Example Functional Test Naming Practice
  622. [php]
  623. $browser->
  624. get('/foobar/index')->
  625. isStatusCode(200)->
  626. isRequestParameter('module', 'foobar')->
  627. isRequestParameter('action', 'index')->
  628. checkResponseElement('body', '/foobar/')
  629. ;
  630. # get /comment/index
  631. ok 1 - status code is 200
  632. ok 2 - request parameter module is foobar
  633. ok 3 - request parameter action is index
  634. ok 4 - response selector body matches regex /foobar/
  635. If you follow this convention, the output of your test will be clean enough to use as a developer documentation of your project--enough so in some cases to make actual documentation useless.
  636. Special Testing Needs
  637. ---------------------
  638. The unit and functional test tools provided by symfony should suffice in most cases. A few additional techniques are listed here to resolve common problems in automated testing: launching tests in an isolated environment, accessing a database within tests, testing the cache, and testing interactions on the client side.
  639. ### Executing Tests in a Test Harness
  640. The `test:unit` and `test:functional` tasks can launch a single test or a set of tests. But if you call these tasks without any parameter, they launch all the unit and functional tests written in the `test/` directory. A particular mechanism is involved to isolate each test file in an independent sandbox, to avoid contamination risks between tests. Furthermore, as it wouldn't make sense to keep the same output as with single test files in that case (the output would be thousands of lines long), the tests results are compacted into a synthetic view. That's why the execution of a large number of test files uses a test harness, that is, an automated test framework with special abilities. A test harness relies on a component of the lime framework called `lime_harness`. It shows a test status file by file, and an overview at the end of the number of tests passed over the total, as you see in Listing 15-32.
  641. Listing 15-32 - Launching All Tests in a Test Harness
  642. > php symfony test:all
  643. unit/myFunctionTest.php................ok
  644. unit/mySecondFunctionTest.php..........ok
  645. unit/foo/barTest.php...................not ok
  646. Failed Test Stat Total Fail List of Failed
  647. ------------------------------------------------------------------
  648. unit/foo/barTest.php 0 2 2 62 63
  649. Failed 1/3 test scripts, 66.66% okay. 2/53 subtests failed, 96.22% okay.
  650. The tests are executed the same way as when you call them one by one, only the output is made shorter to be really useful. In particular, the final chart focuses on the failed tests and helps you locate them.
  651. You can launch all the tests with one call using the `test:all` task, which also uses a test harness, as shown in Listing 15-33. This is something that you should do before every transfer to production, to ensure that no regression has appeared since the latest release.
  652. Listing 15-33 - Launching All the Tests of a Project
  653. > php symfony test:all
  654. ### Accessing a Database
  655. Unit tests often need to access a database. A database connection is automatically initialized when you call `sfTestBrowser::get()` for the first time. However, if you want to access the database even before using `sfTestBrowser`, you have to initialize a `sfDabataseManager` object manually, as in Listing 15-34.
  656. Listing 15-34 - Initializing a Database in a Test
  657. [php]
  658. $databaseManager = new sfDatabaseManager($configuration);
  659. $databaseManager->loadConfiguration();
  660. // Optionally, you can retrieve the current database connection
  661. $con = Propel::getConnection();
  662. You should populate the database with fixtures before starting the tests. This can be done via the `sfPropelData` object. This object can load data from a file, just like the `propel:data-load` task, or from an array, as shown in Listing 15-35.
  663. Listing 15-35 - Populating a Database from a Test File
  664. [php]
  665. $data = new sfPropelData();
  666. // Loading data from file
  667. $data->loadData(sfConfig::get('sf_data_dir').'/fixtures/test_data.yml');
  668. // Loading data from array
  669. $fixtures = array(
  670. 'Article' => array(
  671. 'article_1' => array(
  672. 'title' => 'foo title',
  673. 'body' => 'bar body',
  674. 'created_at' => time(),
  675. ),
  676. 'article_2' => array(
  677. 'title' => 'foo foo title',
  678. 'body' => 'bar bar body',
  679. 'created_at' => time(),
  680. ),
  681. ),
  682. );
  683. $data->loadDataFromArray($fixtures);
  684. Then, use the Propel objects as you would in a normal application, according to your testing needs. Remember to include their files in unit tests (you can use sfSimpleAutoload class to automate it, as explained in a tip in the "Stubs, Fixtures, and Autoloading" section previously in this chapter). Propel objects are autoloaded in functional tests.
  685. ### Testing the Cache
  686. When you enable caching for an application, the functional tests should verify that the cached actions do work as expected.
  687. The first thing to do is enable cache for the test environment (in the `settings.yml` file). Then, if you want to test whether a page comes from the cache or whether it is generated, you should use the `isCached()` test method provided by the `sfTestBrowser` object. Listing 15-36 demonstrates this method.
  688. Listing 15-36 - Testing the Cache with the `isCached()` Method
  689. [php]
  690. <?php
  691. include(dirname(__FILE__).'/../../bootstrap/functional.php');
  692. // Create a new test browser
  693. $b = new sfTestBrowser();
  694. $b->get('/mymodule');
  695. $b->isCached(true); // Checks that the response comes from the cache
  696. $b->isCached(true, true); // Checks that the cached response comes with layout
  697. $b->isCached(false); // Checks that the response doesn't come from the cache
  698. >**NOTE**
  699. >You don't need to clear the cache at the beginning of a functional test; the bootstrap script does it for you.
  700. ### Testing Interactions on the Client
  701. The main drawback of the techniques described previously is that they cannot simulate JavaScript. For very complex interactions, like with Ajax interactions for instance, you need to be able to reproduce exactly the mouse and keyboard input that a user would do and execute scripts on the client side. Usually, these tests are reproduced by hand, but they are very time consuming and prone to error.
  702. The solution is called Selenium ([http://www.openqa.org/selenium/](http://www.openqa.org/selenium/)), which is a test framework written entirely in JavaScript. It executes a set of actions on a page just like a regular user would, using the current browser window. The advantage over the `sfBrowser` object is that Selenium is capable of executing JavaScript in a page, so you can test even Ajax interactions with it.
  703. Selenium is not bundled with symfony by default. To install it, you need to create a new `selenium/` directory in your `web/` directory, and in it unpack the content of the Selenium archive ([http://www.openqa.org/selenium-core/download.action](http://www.openqa.org/selenium-core/download.action)). This is because Selenium relies on JavaScript, and the security settings standard in most browsers wouldn't allow it to run unless it is available on the same host and port as your application.
  704. >**CAUTION**
  705. >Be careful not to transfer the `selenium/` directory to your production server, since it would be accessible by anyone having access to your web document root via the browser.
  706. Selenium tests are written in HTML and stored in the `web/selenium/tests/` directory. For instance, Listing 15-37 shows a functional test where the home page is loaded, the link click me is clicked, and the text "Hello, World" is looked for in the response. Remember that in order to access the application in the `test` environment, you have to specify the `frontend_test.php` front controller.
  707. Listing 15-37 - A Sample Selenium Test, in `web/selenium/test/testIndex.html`
  708. [php]
  709. <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
  710. <html>
  711. <head>
  712. <meta content="text/html; charset=UTF-8" http-equiv="content-type">
  713. <title>Index tests</title>
  714. </head>
  715. <body>
  716. <table cellspacing="0">
  717. <tbody>
  718. <tr><td colspan="3">First step</td></tr>
  719. <tr><td>open</td> <td>/frontend_test.php/</td> <td>&nbsp;</td></tr>
  720. <tr><td>clickAndWait</td> <td>link=click me</td> <td>&nbsp;</td></tr>
  721. <tr><td>assertTextPresent</td> <td>Hello, World!</td> <td>&nbsp;</td></tr>
  722. </tbody>
  723. </table>
  724. </body>
  725. </html>
  726. A test case is represented by an HTML document containing a table with three columns: command, target, and value. Not all commands take a value, however. In this case, either leave the column blank or use `&nbsp;` to make the table look better. Refer to the Selenium website for a complete list of commands.
  727. You also need to add this test to the global test suite by inserting a new line in the table of the `TestSuite.html` file, located in the same directory. Listing 15-38 shows how.
  728. Listing 15-38 - Adding a Test File to the Test Suite, in `web/selenium/test/TestSuite.html`
  729. ...
  730. <tr><td><a href='./testIndex.html'>My First Test</a></td></tr>
  731. ...
  732. To run the test, simply browse to
  733. http://myapp.example.com/selenium/index.html
  734. Select Main Test Suite, click the button to run all tests, and watch your browser as it reproduces the steps that you have told it to do.
  735. >**NOTE**
  736. >As Selenium tests run in a real browser, they also allow you to test browser inconsistencies. Build your test with one browser, and test them on all the others on which your site is supposed to work with a single request.
  737. The fact that Selenium tests are written in HTML could make the writing of Selenium tests a hassle. But thanks to the Firefox Selenium extension ([http://seleniumrecorder.mozdev.org/](http://seleniumrecorder.mozdev.org/)), all it takes to create a test is to execute the test once in a recorded session. While navigating in a recording session, you can add assert-type tests by right-clicking in the browser window and selecting the appropriate check under Append Selenium Command in the pop-up menu.
  738. You can save the test to an HTML file to build a test suite for your application. The Firefox extension even allows you to run the Selenium tests that you have recorded with it.
  739. >**NOTE**
  740. >Don't forget to reinitialize the test data before launching the Selenium test.
  741. Summary
  742. -------
  743. Automated tests include unit tests to validate methods or functions and functional tests to validate features. Symfony relies on the lime testing framework for unit tests and provides an `sfTestBrowser` class especially for functional tests. They both provide many assertion methods, from basic to the most advanced, like CSS selectors. Use the symfony command line to launch tests, either one by one (with the `test:unit` and `test:functional` tasks) or in a test harness (with the `test:all` task). When dealing with data, automated tests use fixtures and stubs, and this is easily achieved within symfony unit tests.
  744. If you make sure to write enough unit tests to cover a large part of your applications (maybe using the TDD methodology), you will feel safer when refactoring internals or adding new features, and you may even gain some time on the documentation task.