Ver índice de contenidos del libro

9.3. La clase sfTestFunctional

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.