Ver índice de contenidos del libro

8.7. Añadir pruebas al corregir un error

Imagina que ya has publicado la aplicación web y uno de tus usuarios te informa de un error bastante extraño: al pinchar los enlaces de algunas ofertas de trabajo se muestra una página de error 404. Después de investigar el error, descubres que esas ofertas de trabajo que están fallando tienen vacíos los campos de la empresa, el puesto de trabajo y/o la localidad. ¿Cómo puede suceder esto? Sigues investigando y ves que las columnas de la base de datos no están vacías.

Después de pensar un poco más, por fin descubres la causa del error. Si una cadena de texto sólo contiene caracteres que no son ASCII, el método slugify() la convierte en una cadena de texto vacía. Como estás tan contento de haber descubierto el error, editas la clase Jobeet y corriges el error directamente. Lo que acabas de hacer no es una buena idea, ya que en primer lugar deberías añadir una prueba unitaria:

$t->is(Jobeet::slugify(' - '), 'n-a', '::slugify() converts a string that only contains non-ASCII characters to n-a');
Fallo descubierto en el método slugify()

Figura 8.4 Fallo descubierto en el método slugify()

Después de comprobar que se produce un error al ejecutar la prueba unitaria, edita la clase Jobeet y mueve la comprobación de si una cadena es vacía al final del método:

static public function slugify($text)
{
  // ...
 
  if (empty($text))
  {
    return 'n-a';
  }
 
  return $text;
}

La nueva prueba unitaria ahora sí que pasa, al igual que siguen pasando todas las anteriores. Aunque el código tenía un 100% de code coverage, el método slugify() tenía un error.

Obviamente no puedes pensar en todos los posibles casos extremos cuando creas pruebas unitarias. Sin embargo, cuando descubres un nuevo caso extremo, debes escribir una prueba unitaria antes de intentar solucionarlo. Además, trabajar de esta manera hace que el código de tu aplicación sea cada vez mejor, lo que es una buena consecuencia de las pruebas unitarias.