#jobeettutorial

Functional Tests

Las pruebas funcionales permiten testear en conjunto una aplicación, desde los request hasta el response pasando por routing y las distintas capas de MVC. Es como testear personalmente cada link cuando añades un cambio a la aplicación.

La diferencia es la misma que en las pruebas unitarias, si lo haces tu pierdes tiempo y con esto garantizas que siempre se hagan las mismas pruebas, tanto en número como variables. Así siempre tendrás el código estable :)

Existe una aplicación llamada Selenium que hace un macro con los tus movimientos por el navegador, no está de más verla en su página oficial.

The sfBrowser class

Para comenzar estas pruebas utilizaremos la clase sfBrowser, que es algo así como un emulador de un navegador en consola, simulando la navegación con los métodos más habituales:

get() Coge una URL

post() Envía una URL

call() Llama a una URL con PUT y DELETE

back() Página anterior en historial

forward() Página siguiente en historial

reload() Recarga la página

click() Pulsa un enlace o botón

select() Seleciona un radiobutton o checkbox

deselect() Deseleciona un radiobutton o checkbox

restart() Reinicia el navegador

Existen otros muchos que puedes consultar en la documentación.

The sfTestFunctional class

Con esto ya podríamos empezar a crear test, entre la clase sfBrowser y lime. pero existe la clase sfTestFunctional que crea una instancia de sfBrowser y tiene muchos test predefinidos.

Por el momento creamos la ruta para los test de la aplicación /test/functional/frontend/ y creamos una prueba para cada uno de nuestros dos módulos... Sorpresa!!! ya están creados, FEEL LIKE A HACKER

La sintaxis es algo extraña porque han usado fluent interface, que es algo así como sobrecargar un objeto con métodos para que sea más legible.

Cada prueba empieza con un with(nombrePrueba)->begin() y termina con end();

The Request Tester

Tiene un conjunto de métodos para probar un sfWebRequest, son bastante básicos por lo que no voy a volver a enumerarlos.

The Response Tester

Igual que el anterior contra un sfWebRespose.

Running Functional Tests

Tenemos el fichero de pruebas con los primeros test, para ver si el routing funciona correctamente, así que lo ejecutamos con:

$ php symfony test:functional frontend categoryActions

Es sencillo, invocas la aplicación y el test (borrando la palabra "test" del final) y ya deberías tener salida, recuerda que la mayoría de los errores que encontrarás con tanto código copypaste serán:

Porque la ruta/fichero no está bien escrito

Porque no has cargado los items en la bd de pruebas

Al menos es lo que me ha pasado a mi :D

Test Data

Cargamos los ficheros, esta vez es más sencillo, creamos nuestra propia clase en /lib/test/JobeetTestFunctional.class.php que hereda de sfTestFunctional.

Aquí me quedé colgado un rato ya que no había puesto el "class".

Writing Functional Tests

Vamos a crear distintos escenarios para la página principal de Jobs, nuestro primero test será comprobar que no lista trabajos expired.

Expired jobs are not listed

 Esto es posible mirando si el selector de CSS encuentra la cadena expired en algún contenedor, todo ello con el método checkElement().

Only n jobs are listed for a category

checkElement() es bastante potente, si añadimos un segundo parámetro (integer) permite devolver TRUE si el número de nodos del contenedor CSS coincide. 

A category has a link to the category page only if too many jobs

Comprobamos que la categoría Design no tiene botón more jobs y que Programming si que lo tiene.

Jobs are sorted by date

Vamos a hacer una función para comprobar sólo si el primero elemento que recibimos es el que realmente es el primero. Como es una consulta SQL debería ir en el modelo, pero al formar parte de los test lo añadiremos a la clase nueva que hemos hecho en /lib/test, refactorizamos para poder utlizar la función más adelante y pasamos a la siguiente.

Each job on the homepage is clickable

Comprobamos que el primer elemento de Web Developer genera correctamente la URL para que el routing no la cague cuando coja esta información.

Learn by the Example

Aquí nos dejan todo el código anterior para evitar cualquier error al juntar las pruebas, los cambios en resumen son:

CategoryActionsTest: Añadimos 4 test funcionales

JobActionsTest: Pruebas enumeradas y otras nuevas

JobeetTestFunctional.class: Cargamos datos y factorizamos dos querys.

Debugging Functional Tests

Como esto del navegador de texto suena muy bien pero para depurar no muestra suficiente información, podemos usar

$browser->with('response')->debug();

Puedes añadirlo en cualquier bloque respose para que pare la ejecución y nos dé más información sobre lo que está pasando.

Functional Tests Harness

Ejecutamos las pruebas de forma conjunta

./symfony test:functional frontend

A mi me dan error un par de ellas, pero creo que es porque he modificado los elementos de la base de datos así que hago la vista gorda.

Tests Harness

Para rizar el rizo vamos a ejecutar las pruebas unitarias y funcionales juntas, sólo hay que hacer un 

$ php symfony test:all

Si estás depurando un programa porque varios test hayan fallado, no hace falta que ejecutes todos desde el principio, tienes un parámetro que se acuerda de los que han fallado y sólo ejecuta esos.

$ php symfony test:all --only-failed

Final Thoughts

Tests in symfony

A veces cuando añadimos una funcionalidad, refactorizamos una clase o simplemente hacemos un cambio, no tenemos ni puta idea si el programa se va a cascar. Symfony te permite realizar una serie de pruebas automatizadas que permiten mantener la ingridad del código, se dividen en:

Pruebas unitarias: prueban que cada método o función devuelve los resultados correctos, es independiente y prueba una cosa cada vez.

Pruebas funcionales: prueban el funcionamiento en conjunto, las veremos en el dia 9.

Todas estas pruebas se almacenan en /test/unit y /test/functional respectivamente.

Unit Tests

No hay que hacer pruebas a todo el software, lo mejor es empezar con los puntos críticos o donde encontremos bugs, nos permitirán mantener el código en una versión estable.

Para ello SF tiene un framework llamado lime para hacer pruebas, también puedes usar PHPunit.

The lime Testing Framework

Todas las pruebas de test empiezan igual, el número en lime_test() indica el número de pruebas que se van a realizar.

require_once dirname(__FILE__).'/../bootstrap/unit.php'; $t = new lime_test(1);

auque podríamos depurar todo con un método ok(), nos devuelve TRUE si lo cumple o FALSE en caso contrario, SF tiene un conjunto de métodos que nos ayuda a depurar o filtrar.

ok($test) Test a una condición y la pasa si es TRUE

is($value1, $value2) Compara dos valores y pasa si son iguales

isnt($value1, $value2) Compara dos valores y pasa si NO son iguales

like($string, $regexp) Prueba un string si cumple una expresión regular

unlike($string, $regexp) Prueba un string si NO cumple una expresión regular

is_deeply($array1, $array2) Compara dos arrays, pasa si son iguales

fail() Siempre falla, útil para test de excepciones

pass() Siempre pasa, útil para test de excepciones

skip($msg, $nb_tests) Cuenta el número de test, útil para condicionales

todo() Para test que todavía no están hechos ¿?

Por último hay un test llamado comment($msg) que muestra un mensaje pero no hace ningún test.

Running Unit Tests

Empezamos a crear el primer fichero de test, la nomenclatura es /test/unit/Nombre_CaseTest. CopyPaste y lo ejecutamos mediante:

$ php symfony test:unit Jobeet

Testing slugify

Durante el día 5 hemos creado unos parseadores que llamamos slugify para hacer las beautyURLs, su trabajo era:

pasaban todo a minúsculas

transformaban espacios y caracteres no-ASCII en guiones "-"

Seguimos los pasos, recuerda PRUEBA UNA ÚNICA COSA EN CADA TEST. Vamos a usar el método is() para comprobar distintas entradas y ver que formatea correctamente, todas las pruebas permiten un último parámetro de comentarios que nos sirve para documentar las pruebas.

Si queremos ser más papistas que el Papa, podemos bajarnos Xdebug para que nos diga si se han testeado todas las líneas del código, OJO los casos extremos los debemos crear nosotros, esto sólo cuenta líneas.

Yo paso por el momento... ;)

Adding Tests for new Features

Slug tiene algunos errores, por ejemplo si viene una cadena vacía, devuelve vacío y eso es caca cuando vayamos a crear una URL. Creamos primero el test y luego implementamos la funcionalidad, esta metodología se llama TDD.

Ahora añadimos la funcionalidad en la clase Jobeet y todo debe ir bien.

Adding Tests because of a Bug

Vamos a seguir mejorando el código, en este caso si un campo tiene sólo caracteres noASCII termina devolviendo la cadena vacía, creamos la prueba y modificamos el código.

Las vocales con acento también las cambia a guiones, utilizaremos la función iconv() este caso llamado "transliteration". No me queda muy claro donde tiene esta librería instalada pero funciona.

Doctrine Unit Tests

Es recomendable crear una bd dedicada para los test, SF puede utilizar una base de datos distinta para cada entorno por lo que crearemos una con el siguiente comando.

Database Configuration

$ php symfony configure:database --name=doctrine --class=sfDoctrineDatabase --env=test "mysql:host=localhost;dbname=jobeet_test" root PASSWORD

Puedes ver en /config/databases.yml como ha creado todo lo que necesita, pero todavía no tenemos ni la base de datos ni las tablas creadas. Para ello entro en phpmyadmin y creo jobeet_test. Luego cargo las tablas de desarrollo.

$ php symfony doctrine:insert-sql --env=test

La mayoría de los ficheros de configuración de la aplicación que están en YAML (databases, app, view, settings) permiten configurar los distintos entornos o utilizar el mismo con la clave all.

Test Data

Lo que hago a continuación es copiar los datos por defecto de /data/fixures a /text/fixures para que cuando haga el loadData(), más tarde pueda encontrarlos.

Testing JobeetJob

Ahora vamos a crear las pruebas unitarias en /test/bootstrap/Doctrine.php, en este archivo definiremos la cabecera muy parecida a la anterior, la conexión a la base de datos y la funcionalidad que vamos a testear.

Doctrine sólo conecta a la base de datos hasta que tiene querys para ejecutar, así que por el momento no podemos probar nada. Copiamos los archivos de /data/fixtures a /test/fixtures, ya que el método loadData() es capaz de coger archivos, directorios y todo su contenido.

CopyPaste del archivo creado y lo ejecutamos desde consola con

php test/bootstrap/Doctrine.php

Ahora hemos creado las tuplas dentro de las tablas, que estaban vacías. Si tienes un error porque no puede instanciar los objetos, puede ser que las tablas estén vacías. Nos queda añadir la funcionalidad a las pruebas que queremos realizar antes de ejecutarlas con:

./symfony test:unit JobeetJob

Recuerda que no hay que poner Test al final.

Test other Doctrine Classes

Puedo hacerlo para las otras clases pero por el momento no lo veo prioritario.

Unit Tests Harness

Podemos hacer un symfony test:unit que nos da la salida de todos los test de la aplicación juntos, muy profesional

Final Thoughts

Vamos a añadir una nueva funcionalidad a la aplicación, se trata de un nuevo módulo categoría, para casi todo en SF hay que seguir esta rutina:

Creas Rutas-> Creas Actions -> Creas Modelo -> Actualizas Vista

The Category Route

En routing es donde se demuestra si has pensado antes de picar código, estudia detenidamente los requisitos de tu aplicación, así como el comportamiento esperado y los parámetros que necesitas.

Vamos a crear una nueva ruta para categorías, todas las rutas posibles deberían estar contempladas en el momento que desactivamos el default, pero bueno estamos aprendiendo.

Creamos la ruta por copypaste... vamos con Actions y Modelo

The Category Link

Aunque el tutorial no sigue el orden estrictamente, en este punto modificamos:

VISTA indexSuccess.php para que pinte el enlace en la plantilla

CONTROLADOR no hay que cambiar nada en Actions ya que sigue siendo executeIndex()

MODELO refactorizamos la clase JobeetJob, ahora tenemos la query únicamente en addActiveJobsQuery() recuerda Dont Repeat Yourself (DRY) añadimos la lógica que necesitamos para la clase JobeetCategory.class.php

Job Category Module Creation

Crearemos ahora un módulo nuevo, podríamos añadirlo como un action dentro del módulo jobs, pero tiene más sentido crearlo para su propia página "categoría".

Para ello ejecutaremos

$php symfony generate:module frontend category

Para el carro... no es doctrine:generate-module? Sí, pero como no nos hace falta que doctrine nos cree nuevas clases para el modelo (sí, como ves podría haber sido un simple action) utilizamos genera:module a secas.

Update the Database

Actualizamos el esquema de la base de datos para añadir el campo "slug", ahora ya no necesitamos el método getSlug() de JobeetCategory. Por otro lado entramos en el controlador del nuevo módulo Category, vamos a editar el método executeShow() y nos creamos showSuccess.php.

Fijate como ya no vamos a redirigir a index, nos podemos cargar el archivo.

Partials

Este punto nos explica como podemos insertar trozos de plantilla que se repiten, creamos un archivo _PLANTILLA.php, ahora podemos invocarlo desde el helper include_partial().

<?php include_partial('job/list', array('jobs' => $jobs)) ?>

Esto es muy similar a usar un include() normal de PHP, la principal diferencia es que el helper puede tirar de caché por lo que será más rápido.

List Pagination

Symfony tiene una clase de paginación para Doctrine sfDoctrinePager, que contiene todos los métodos necesarios para su funcionamiento. Lo vamos a insertar en el controlador de Categorías, para que en vez de pasarle una lista de objetos a showSuccess() le envie el paginador.

Le indicamos la página 1 para cualquier caso donde no tenga variable, también definimos el número de elementos en app.yml . Por último facturizamos el modelo JobeetCategory.class, hacemos esto porque los 3 métodos de la clase son muy parecidos.

Sólo nos queda actualizar la vista, que va a tirar de los siguientes métodos del paginador: 

getResults(): Devuelve un array de objetos Doctrine para la página actual

getNbResults(): Devuelve el número total de resultados

haveToPaginate(): Devuelve TRUE si hay más de una página

getLinks(): Devuelve una lista de links de paginación

getPage(): Devuelve la página actual

getPreviousPage(): Devuelve la página anterior

getNextPage(): Devuelve el próximo número de página

getLastPage(): Devuelve el último número de página

La clase del paginador también incluye un iterator y un count() para poder operar con ellos.

Final Thoughts

URLs

Cuando pulsamos sobre un trabajo en Jobeet, nos enseña una ruta extraña que nada tiene que ver con lo que esperamos en PHP.

  /job/show/id/1

Vamos a ver como SF desglosa este tipo de URLs, lo primero recordar que una URL es una dirección única de un recurso web, que en muchos casos, viene acompañada de datos necesarios para que nos devuelva el resultado que esperamos.

SF entiende que www.ruta.com?id=valor supone una vulnerabilidad ya que expone la estructura de nuestro sistema y compromete la seguridad. Su solución es un framework que "enruta" o redirige las URLs de entrada a unas URIs (ruta de los ficheros php) mediante comprobaciones como tipo de objeto, número de parámetros o permisos... toda una joya.

Routing Configuration

Este sistema está definido en routing.yml, que contiene un conjunto de rutas. Cada ruta está definida por un:

Nombre: identificador del mismo

Patrón: estructura de la ruta

Parámetros: parámetros que vienen en la misma

Cuando llega una petición, routing.yml intenta cuadrar esa URL con un recurso URI. Lo hace secuencialmente, el primero que encaja gana, por lo que hay que tener cuidado con el orden. Otro detalle es que en el patrón, a partir de /* define un conjunto de variables separadas por "/".

Estas rutas suelen ser utilizadas con el helper url_for() que hemos visto antes

url_for('job/show?id='.$job->getId()) url_for('@default?module=job&action=show&id='.$job->getId())

Como podeis ver, al usar la @ podemos marcar todos los valores, lógicamente es mucho más rapida ya que no tiene que comprobar en routing list y según la documentación es más flexible :p

Route Customizations

Empezamos a hacer algunos cambios, si estás en producción recuerda que si tocas el routing debes limpiar la caché, el comando es:

  php symfony cc

Recuerda que poner beauty URL es muy importante tanto para que los usuarios vean con más claridad a donde les lleva un enlace, donde están o lo más importante; influye en el SEO.

Requirements

Los requeriments permiten definir expresiones regulares, por ejemplo que una variable sea un integer o un objeto.

Route Class

También podemos definir el tipo de método GET, POST, HEAD, DELETE y PUT, ya hemos visto que symfony encapsula todas estas peticiones en objetos, podemos indicar que esperamos un método en concreto.

Object Route Class

Cuando he usado el url_for() para construir la URI me he quedado un poco decepcionado... muchos parámetros en un array pueden hacer que cometamos fallos, eso debió pensar el bueno de Fabian (si no sabes el día 5 quien ha inventado este fregao, hazte un sudo reboot)

Por eso se le ocurrió la clase sfDoctrineRoute, donde podemos indicar que esta ruta va a coger un objeto type:object (o un conjunto de ellos type:list) generado por el ORM. Ahora sólo tenemos que ir al helper para marcar ruta y objeto.

  url_for('job_show_user', $job)

A partir de aquí nos enseñan a crear un accesor para limpiar la URL, mostrando correctamente los caracteres extraños, el routing es muy potente y no sólo nos permite crear una URL a partir de un objeto, sino que además es capaz de encontrar un objeto a partir de una ruta.

Routing in Actions and Templates

En una plantilla, el helper url_for() convierte una URI interna en una URL externa. Existen otros helpers en SF que también toman una URI como argumento, por ejemplo link_to() que genera un tag <a>. Vamos a ver un par de ejemplos:

El código... <?php echo link_to($job->getPosition(), 'job_show_user', $job) ?>

Genera... <a href="/job/sensio-labs/paris-france/1/web-developer">Web Developer</a>

También es posible generar URLs absolutas... link_to($job->getPosition(), 'job_show_user', $job, true)

O generarlas desde un action con el método generateUrl()...  $this->redirect($this->generateUrl('job_show_user', $job)); 

Para terminar el punto, destacar que existen varios métodos para hace redirect(), redirectIf() y redirectUnless() que envian el request a otro action sin que lo tenga que procesar el navegador

Collection Route Class

La regla default está cogiendo todas las rutas por el momento, esto es bueno para ver algo funcional desde el principio pero carece de funcionalidad para el resto de métodos de la aplicación, digamos que es como un mockup.

Con los conocimientos actuales definiríamos una ruta/regla para cada función que quisieramos con la clase sfDoctrineRoute, si como en este caso, son los 7 métodos genéricos de CRUD (index, new, create, edit, update, delete, show) podemos usar sfDoctrineRouteCollection que nos lo generará automáticamente.

job:     class:   sfDoctrineRouteCollection     options: { model: JobeetJob }

Como los métodos DELETE y PUT no está admitidos por todos los navegadores, SF los parsea como puedes ver en el archivo apps/frontend/modules/job/templates/_form.php

Route Debugging

Puedes obtener información general del routing de la aplicación ejecutando

$ php symfony app:routes frontend

También puedes obtener información de un modulo en particular con 

$ php symfony app:routes frontend job_edit

Default Routes

La prueba de fuego, ya que hemos definido rutas para todos los action de la aplicación, ya no necesitamos la ruta default por lo que la comentamos, la aplicación debería seguir funcionando.

Final Thoughts

El archivo routing.yml sirve de semáforo para manejar las URLs públicas y transformarlas en URIs internas, o viceversa. También es el encargado de llamar a un action asociado y parsear parámetros.

Sólo nos queda hablar de:

Slots

Error 404 en distintos entornos

Request y Response 

Los Slots

Ya hemos visto el patrón decorator, que es el que utiliza symfony. Además es posible insertar bloques o slots, que acompañan a la template, todo ello será renderizado/pintado mediante layout.php

Error 404

Symfony diferencia el entorno sobre el que trabajas, desarrollo o producción para ofrecer una vista con más información si es el desarrollador el que se enfrenta a un 404, por el contrario si es un usuario en producción devuelve una página más corporativa.

Todo ello se puede controlar por objetos, en este tutorial te redirige a no ser que tenga un objeto job.

Request y Response

Toda plataforma cliente servidor se comunica mediante peticiones Request y respuestas Response. Symfony encapsula en sfWebRequest y sfWebResponse.

El objetivo es utilizar el mismo paradigma todo el tiempo, facilitando además el trabajo al desarrollador, ya que siempre será más fácil emular o construir este tipo de elementos para las pruebas.

En Symfony, dentro de cada módulo hay un fichero llamado actions.class.php, este es el controlador. Tiene un conjunto de métodos que enrutan la información que ÉL obtiene del modelo.

Symfony asocia los métodos del controlador que empiecen por execute con las vistas, por ejemplo executeIndex.php intentará  ejecutarlo con la vistaindexSuccess.php

Hablando en plata, este actions habla con doctrine para pedirle lo que sea de la base de datos, lo procesa y se lo manda a la vista/template que tenga de ruta, como por ejemplo indexSuccess.php.

Por lo demás sólo falta mencionar como invoca a un helper que no está cargado en la vista de Show, 

<?php use_helper('Text') ?>

y como enlaza a otra URL (en este caso Show) para que el controlador vuelva a enrutar y pase los parámetros mediante 

<?php echo url_for('job/edit?id='.$job->getId()) ?>

Todo lo que vimos ayer podía haberse solucionado con un miserable

  $ php symfony doctrine:build --all --no-confirmation

Pero en fin, así hemos aprendido algo xD Vale ahora en serio, es importante saber que por cada tabla SF genera tres archivos, por ejemplo sobre la tabla JobeetJob:

- JobeetJob:nos crea un objeto por cada tupla, es decir pasa la tabla a objetos, por defecto está vacía.

- BaseJobeetJob:padre de la anterior, cada vez que haces un doctrine:build --model la clase se sobreescribe, por eso no hay que tocarla.

- JobeetJobTable:en el tutorial dice "define métodos sobre colecciones de objetos" no tengo ni idea por el momento.

Me descargo las imágenes y genero los dos archivos yaml con los fixures "categories" "jobs", guardo todo en su sitio. Ahora ejecuto

php symfony doctrine:build --all --and-load 

Recuerda que son dos archivos los que tienes que crear, no puedes pegar todo a pelo. Ahora vamos a crear un módulo CRUD para editar los trabajos.

php symfony doctrine:generate-module --with-show --non-verbose-templates frontend job JobeetJob

La sintaxis dice "crea un módulo JOB en la aplicación FRONTEND para el modelo JOBEETJOB"

Este módulo tiene sus propios actions/ donde se mete la lógica y sus templates/ todo ello lo veremos más adelante. Ya puedo entrar en:

http://pit.jobeet.com/frontend_dev.php/job

aquí me ha generado el código por defecto, aquí está la potencia de SF, tenemos el sistema CRUD funcionando, reconoce el tipo de datos y los muestra en textfield u optionbox, además de añadir funciones como "required" en los campos.

Ya tengo todo instalado MySQL y Netbeans, además he copiado PhpMyAdmin a la carpeta /Usr/Pit/Sites

Por el momento no me permite acceder el login, puedo entrar por consola a mysql así que no me preocupo por el momento.

Entro por terminal y creo la bd:

mysql -u root -p

CREATE DATABASE jobeet;

Salgo de ahí, el tutorial hace dos tareas por terminal pero vamos a editar los documentos que es más claro:

/config/schema.yaml -> ya tengo que tener copypaste y guardado /config/databases.yaml -> pongo las credenciales y la bd sobre la que trabajaré 

ahora voy a ejecutar los comandos de doctrine:

php symfony doctrine:build --model php symfony doctrine:build --sql

ahora voy a ejecutar los comandos de doctrine, estos comandos no ejecutan nada en la bd sólo crean los archivos y modelos que usaremos a posteriori, la prueba de fuego es ejecutar:

php symfony doctrine:insert-sql

lógicamente no funciona a la primera así que busco un par de manuales más:

http://hivelogic.com/articles/installing-mysql-on-mac-os-x/ http://railsforum.com/viewtopic.php?id=40130 

el segundo, me dice que es culpa de /etc/php.ini y tengo que editar las líneas /var/mysql/mysql.sock y sustituirlas por /tmp/mysql.sock

así que me voy a por él y lo cambio las 3 veces que sale, reseteo apache y mysql, ahora todo funciona, ejecuto

php symfony doctrine:insert-sql