Aunque ya disponemos de un navegador, todavía no es posible la introspección de los objetos de Symfony para realizar las pruebas y comprobaciones. Esta introspección se podría realizar con lime
y los métodos getResponse()
y getRequest()
de sfBrowser
, pero Symfony permite hacerlo de otra forma mejor.
Los métodos para pruebas se incluyen en otra clase llamada sfTestFunctional y que utiliza como argumento de su constructor un objeto de tipo sfBrowser
. La clase sfTestFunctional
delega las pruebas en objetos de tipo tester. Symfony ya incluye varios testers, pero también puedes crear todos los testers propios que necesites.
Como se vio en la lección de ayer, las pruebas funcionales se almacenan en el directorio test/functional/
. Las pruebas de Jobeet se almacenan en el subdirectorio test/functional/frontend/
, ya que cada aplicación utiliza su propio subdirectorio. Este directorio ya contiene dos archivos llamados categoryActionsTest.php
y jobActionsTest.php
, ya que todas las tareas que generan módulos de forma automática crean un archivo muy básico de pruebas funcionales:
// test/functional/frontend/categoryActionsTest.php
include(dirname(__FILE__).'/../../bootstrap/functional.php');
$browser = new sfTestFunctional(new sfBrowser());
$browser->
get('/category/index')->
with('request')->begin()->
isParameter('module', 'category')->
isParameter('action', 'index')->
end()->
with('response')->begin()->
isStatusCode(200)->
checkElement('body', '!/This is a temporary page/')->
end()
;
Al principio, el código anterior puede parecerte un poco extraño. El motivo es que los métodos de sfBrowser
y sfTestFunctional
siempre devuelven el objeto $this
para permitir lo que se conoce con el nombre de interfaz fluida. De esta forma, es posible encadenar varios métodos para mejorar la facilidad de lectura del código. El código anterior es equivalente a:
// test/functional/frontend/categoryActionsTest.php
include(dirname(__FILE__).'/../../bootstrap/functional.php');
$browser = new sfTestFunctional(new sfBrowser());
$browser->get('/category/index');
$browser->with('request')->begin();
$browser->isParameter('module', 'category');
$browser->isParameter('action', 'index');
$browser->end();
$browser->with('response')->begin();
$browser->isStatusCode(200);
$browser->checkElement('body', '!/This is a temporary page/');
$browser->end();
Las pruebas se ejecutan dentro de un contexto de bloque de tester. Los contextos de bloque de testers siempre empiezan por with('NOMBRE_DEL_TESTER')->begin()
y terminan con end()
:
$browser->
with('request')->begin()->
isParameter('module', 'category')->
isParameter('action', 'index')->
end()
;
El código anterior prueba que el parámetro module
de la petición sea igual a category
y el parámetro action
sea igual a index
.
Nota Si sólo vas a utilizar un método del tester, no es necesario que crees un bloque: with('request')->isParameter('module', 'category')
9.3.1. El tester request
El tester request
incluye métodos para realizar la introspección y probar los objetos de tipo sfWebRequest
:
Método | Descripción |
---|---|
isParameter() |
Comprueba el valor de un parámetro de la petición |
isFormat() |
Comprueba el formato de la petición |
isMethod() |
Comrpueba el método utilizado |
hasCookie() |
Comprueba si la petición incluye una cookie con el nombre indicado |
isCookie() |
Comprueba el valor de una cookie |
9.3.2. El tester response
También existe un tester response
que incluye los métodos equivalente para los objetos de tipo sfWebResponse
:
Método | Descripción |
---|---|
checkElement() |
Comprueba si un selector CSS sobre la respuesta cumple el criterio indicado |
isHeader() |
Comprueba el valor de una cabecera |
isStatusCode() |
Comprueba el el código de estado de la respuesta |
isRedirected() |
Comprueba si la respuesta actual es en realidad una redirección |
Nota Durante los próximos días explicaremos muchos otros testers utilizados para formularios, usuarios cache, etc.