15.4. Recomendaciones sobre el nombre de las pruebas

En esta sección se presentan algunas de las buenas prácticas para mantener bien organizadas las pruebas y facilitar su mantenimiento. Los consejos abarcan la organización de los archivos, de las pruebas unitarias y de las pruebas funcionales.

En lo que respecta a la estructura de archivos, los archivos de las pruebas unitarias deberían nombrarse según la clase que se supone que están probando y las pruebas funcionales deberían nombrarse en función del módulo o escenario que se supone que están probando. El listado 15-29 muestra un ejemplo de estas recomendaciones. Como el número de archivos en el directorio test/ puede crecer muy rápidamente, si no se siguen estas recomendaciones, es posible que sea muy difícil encontrar el archivo de una prueba determinada.

Listado 15-29 - Ejemplo de recomendaciones sobre el nombre de los archivos

test/
      unit/
        miFuncionTest.php
        miSegundaFuncionTest.php
        foo/
          barTest.php
      functional/
        frontend/
          miModuloActionsTest.php
          miEscenarioTest.php
        backend/
          miOtroEscenarioTest.php

En las pruebas unitarias, una buena práctica consiste en agrupar las pruebas según la función o método y comenzar cada grupo de pruebas con una llamada al método diag(). Los mensajes de cada prueba unitaria deberían mostrar el nombre de la función o método que se prueba, seguido de un verbo y una propiedad, de forma que el resultado que se muestra parezca una frase que describe una propiedad de un objeto. El listado 15-30 muestra un ejemplo.

Listado 15-30 - Ejemplo de recomendaciones para las pruebas unitarias

// strtolower()
$t->diag('strtolower()');
$t->isa_ok(strtolower('Foo'), 'string', 'strtolower() devuelve una cadena de texto');
$t->is(strtolower('FOO'), 'foo', 'strtolower() transforma la entrada en minúsculas');

# strtolower()
ok 1 - strtolower() devuelve una cadena de texto
ok 2 - strtolower() transforma la entrada en minúsculas

Las pruebas funcionales deberían agruparse por página y deberían comenzar con una petición. El listado 15-31 muestra un ejemplo de esta práctica.

Listado 15-31 - Ejemplo de recomendaciones para las pruebas funcionales

$browser->
  get('/foobar/index')->
  isStatusCode(200)->
  isRequestParameter('module', 'foobar')->
  isRequestParameter('action', 'index')->
  checkResponseElement('body', '/foobar/')
;

# get /comment/index
ok 1 - status code is 200
ok 2 - request parameter module is foobar
ok 3 - request parameter action is index
ok 4 - response selector body matches regex /foobar/

Si se sigue esta recomendación, el resultado de la prueba es lo suficientemente claro como para utilizarlo como documentación técnica del proyecto, ya que puede hacer innecesaria la propia documentación de la aplicación.