Testing aplicado en Symfony2

Extracto de la transcripción automática del vídeo realizada por YouTube.

el único punto de fallo va muy relacionado con el tema del single responsability valiosa de la responsabilidad única de un método un método una única cosa código bien estructurado cada cosa hace una única una única función vale entonces ya es el primer enfoque

unitario nos va a llevar a acercarnos entre comillas a estructurar mejor nuestro código no ese código donde metemos todo a piñón evidentemente no vamos a conseguir que explote una única cosa con esa orientación en cambio si lo hacemos todo paso a paso sí integración

muy simple lo que no debemos colaborar o sea confiar en los colaboradores pero sí que queremos ver que funciona todo unido o sea yo tengo un trozo y sé que es cojonudo pero lo que no puede ser es que ese trozo funcione y otro trozo también funcione pero no

hayamos comprobado que todo junto funciona lo que a mí me importa es que acá para acá para la aplicación que yo estoy construyendo funcione de acuerdo cual es la extracción de un test de interacción no tiene hasta se vale o la abstracción nunca solitaria vale

porque lo que quiero ver es la cadena de enlaces de todo lo que estoy construyendo para ver qué funciona de acuerdo y la siguiente capa el top ya estaríamos hablando de tests funcionales donde lo que vamos a probar realmente es la aplicación completa en el

caso de symphony vamos a tener un kernel debajo vale y la extracción es toda la aplicación vale entonces este pequeño repaso nos encontramos con la pirámide del testing entre comillas vale donde daría la importancia y la cantidad de tests que vamos a tener

en nuestra aplicación si cubrimos capa a capa de esta forma la capa unitaria tiene que ser mucho más grande vale que la capa de interacción y a su vez la capa funcional vale porque como hemos visto antes desde la extracción unitaria vamos a ir a puntos concretos

del código dónde va a explotar algo donde se rompe algo va a fallar ese punto con lo cual la cobertura unitaria tiene que ser muy amplia para que cuando estemos desarrollando en una aplicación grande si se rompe algo sea fácil encontrar el punto y solucionar

el problema no cuál es el valor de un test es una pregunta obvia pero muchas veces nos olvidamos de esto el testing a la gente que le gusta pues es un poco como pajas mentales muchas veces de conversaciones de café que se suele decir donde se empieza a divagar

y el té se enfocaría así ya se está muy bien vale estas lides de álvaro del año pasado y realmente nos enseña que es que para nosotros un test simplemente es una herramienta de desarrollo ya está entonces nosotros nos pagan por desarrollar funcionalidades

que nuestra empresa quiera nada más hay que pensar dos veces antes de escribir un test desde el punto de vista de que primero pensamos en que el test es mi herramienta de desarrollo pero luego voy a tener que explotar ese código o sea eso quiere decir que

si yo tengo una batería de tres enormes mal estructurada cada vez que toque algo y se rompa algo o tenga que añadir un cambio a mi código eso me va a llevar a montones de cambios detrás vale y montones de tests rotos vale con lo cual es importante saber dónde

quiero testear y cómo lo voy a hacer los tests son herramientas vale cuando pensamos en los tests normalmente localizamos así cambio algo para ustedes veo que funciona todo estoy tranquilo ok vale pero eso no nos debe ocultar que es el vehículo perfecto para

desarrollar mucha gente empieza desarrollando un trocito de código en algún lado que prueba y no sé que ese es el punto de inicio perfecto para hacer un test y luego a partir de ahí ir desarrollando lo que están haciendo con lo cual te va a acompañar en todo

el flujo de desarrollo y luego hay otro punto muy importante que es el feedback que nos pueden dar los tests los tests realmente lo que van a hacer es utilizar nuestro código con lo cual vamos a vamos a poder si así nosotros vemos el feedback que nos está

dando en los tests vamos a ver cómo es nuestro código y eso nos va ayudar a entender cómo mejorarlo después cómo plantearlo vale desde el enfoque del driver development veremos que es mucho más sencillo importante aceptar es sólo que lo que necesitamos lo

mínimo vale precisamente para evitar ese lastre de explotación ese lastre explotación normalmente cuando se está desarrollando no se ve pero en aplicaciones muy grandes eso es un problema serio porque realmente requiere mucho tiempo o sea tú piensas cuando

hablamos de planificaciones decimos cuánto tiempo vas a tardar en desarrollar x y nosotros pensamos hostia pues esto voy a hacerlo así asá voy a tardar un día vale lo que no pensamos es si se rompe toda la batería de nuestros tests toda la suite cuánto tiempo

voy a tardar en recuperar todas esas de suite para esos tiempo que también consumo se llama entregar una funcionalidad rompiendo toda la batería de test y es un tiempo que tengo que estimar con lo cual es muy importante el hasta de explotación cuando acabamos

o sea toda esta charla realmente está montada desde el testing aplicado del band el symphony 2 erlán bank del que es para la charla de mañana con jordi y son las necesidades que hemos tenido al desarrollar esa aplicación uno de los tests por ejemplo se dedica

a hacer recurrentemente una llamada entre un socket server y uso que es un bucle que lo hace mil veces vale el objetivo de ese test en concreto era simplemente determinar si todo era estable si no un flujo de funcionamiento normal todo iba a ser estable y

eso ayudó a encontrar un pequeño back sobre el tamaño del buffer de entrada del socket x en cualquier caso de ese tipo de test no es el test normal que voy a utilizar en mi explotación me va a ayudar después de cara a buscar performance no a buscar asegurarme

la profundidad de mis test pero no es el test normal y corriente que quiero vale por eso debemos categorizar un poquito entre comillas como son nuestros test igual tengo test que en desarrollo me ayuda mucho y en explotación van a ser más un problema que es

una solución entonces importante el enfoque que vamos a tener por tanto es muy importante planificar la suite si ya la gente desarrolla unitariamente driver development como quieres llamarlo si ellos desarrollan normalmente cuando entregó ya me olvido toda

una tesis cuando se convierte en algo muy grande es algo que hay que pensar y hay que ver cómo se ejecuta los tests tienen que ser rápidos para ser eficaces si una batería de test en ejecutarse tarda 10 minutos no lo va a ejecutar medios y lo que a mí me interesa

es que sea una herramienta que me ayude en mi tiempo no que me voy a tomar un café y deje los tests ejecutándose sino que sea todo rápido igual me interesa separarlo por tipos de testing por el tiempo de ejecución por lo que sea por eso el 100% de cobertura

del código lo vemos como un pequeño paraíso no estoy seguro de que no roto nada y es genial es así vale pero luego hay que pensar en ese recargo que estamos soportando o sea ese de trabajo que es soportar la rotura de los tests arreglarlos osea eso es una

carga importante y hay que tenerlo muy en cuenta al fin y al cabo te acabas dando cuenta de que quizá el enfoque práctico es el que más me gusta sinceramente hay mucha filosofía y mola mucho pero esta es la realidad o sea para mí un valor del valor del test

[ ... ]

Nota: se han omitido las otras 3.561 palabras de la transcripción completa para cumplir con las normas de «uso razonable» de YouTube.