Páginas

lunes, 1 de febrero de 2016

Diseñando una aplicación desde cero parte 2

Buen día, en la entrada anterior obtuvimos un diagrama de clases según un requerimiento ahora comenzaremos a convertir este diagrama en una app funcional, para esto podemos utilizar cualquiera de los frameworks de la variedad que tenemos en php (symfony, laravel, yii, zend, etc.) o incluso php puro y duro (para mi usar un framework opción super recomendada), en esta entrada se trabajará con symfony2.8 destacando que no es un tutorial de como trabajar con symfony por lo que no se explicará estructura del framework ni nada por el estilo, el punto es ir haciendo la aplicación según el diseño, el mismo diseño debería de servir para cualquier otro y ya con las manos en el código se mostrará como ir aplicando Test Development driver TDD a nuestra aplicación, por supuesto usando PHPUnit como framework base paras las pruebas unitarias.

Lo primero es conocer un poco de TDD, en síntesis la teoría es la siguiente, escribe la test de la funcionalidad a aplicar, corre el test y estarás en rojo, realiza el código para que la test funcione y pasa a verde, el punto principal es que según el diseño que se pensó para la aplicación se vayan realizando las test y codeando la funcionalidad, no es hacer un millón de test y luego ir al código sino al contrario, escribe test, escribe el condigo necesario de la funcionalidad para que ella pase a verde y pasa a la siguiente test, repite hasta que termines la app (suena divertido :)). Aplica refactory si es necesario (no es el tema principal en este artículo pero es parte del ciclo de TDD), ahora sí manos al código.

Según el diagrama diseñado en la entrada anterior tenemos una entidad Album y una Artista por lo que lo primero que tenemos que hacer son comenzar las test de nuestra entidad, para ello en la carpeta de test escribimos lo siguiente


https://gist.github.com/carlosbelisario/71c1ba6b81ce22943a5b

Como podemos ver, la test es simple y se autocomenta (importante para las test ya que las mismas no sirven de doc muchas veces) y lo que probamos es que haya instancia de nuestra entity a testear. Una vez culminado el código de la test procedemos a correrlo lo cual nos dará como resultado

.PHP Fatal error:  Class 'AppBundle\Entity\Album' not found ...


Es lo esperado según la técnica que estamos usando, el test esta en rojo ¿por que? obviamente no hemos aún creado nuestra entidad, en el caso de symfony podemos hacer uso de su consola para crearla o podemos hacerlo a pie (a gusto del consumidor) y obtendremos

https://gist.github.com/carlosbelisario/714a37a94c6c0258b64d

si volvemos a correr nuestra test ahora si tendremos el verde que deseamos y si ya finalizamos la primera test, simple cierto.

Seguimos revisando nuestro diseño y vemos que nuestra entidad tiene comportamiento que debemos testear, si tenemos un método para añadir los artistas a nuestro album y según la cardinalidad podemos agregar muchos artistas al mismo, doctrine nos provee de un tipo de datos llamado ArrayCollection que implementaremos en la entidad, pero vayamos a la test

https://gist.github.com/carlosbelisario/790574b289899627a5e7

Como se puede observar, la test cambio un poco añadimos un método setUp para inicializar en cada test nuestro objeto a testear Album en este caso, y se añadió la funcionalidad que se necesita si volvemos a correr la test encontraremos que estamos en rojo nuevamente y ¿que tenemos que hacer? realizar el código para pasar a verde, el cual para nuestro caso será el siguiente.

https://gist.github.com/carlosbelisario/283f67b5adeb06168937

Volvemos a correr la test y ya nuevamente todo en verde, en este punto podemos ver que tenemos setter y getter dentro de nuestra entidad (el comando de consola de doctrine es genial y nos creo todos los que necesitamos) la pregunta del millon

¿se deben hacer test de todos los getter y setter?

En mi opinión personal no, solo si tienen alguna lógica específica se deberían de hacer test, documentandome sobre el tema he leído personas que concuerdan con este punto, pero todo es cuestión de puntos de vistas y opiniones

Como podemos ver ya hemos implementado las test de la primera entidad (el comando de consola de doctrine nos apoyo con el segundo método que faltaba) el cual podemos ver su test aquí

https://gist.github.com/carlosbelisario/770c537ca6802cb6c80b

Antes de concluir es importante indicar que una test en rojo no significa que sea un error y una test en verde no significa que la test este 100% correcta siempre hay que tener en cuenta el concepto de refactory para nuestras test y nuestro código de manera que el software que tengamos sea software de calidad.

Espero que la entrada sea de agrado cualquier comentario o mejora será bien recibido y recordar hay que crear test verlas en rojo y luego pasar a verde. Saludos