Cuando estamos involucrados en un proyecto, tirando de líneas de código como locos, en muchas ocasiones, nos entran dudas de que es lo que debemos de probar, que casuísticas son las que deben de generar test que nos hagan saber si lo que estamos haciendo, es lo que debería.
En la gran mayoría de ocasiones, siempre vamos a probar lo que creemos que va a fallar, lo obvio y lo que nos genera dudas, de esta manera, nuestro cerebro enlaza que están cubiertas las zonas oscuras de nuestro código y por lo tanto, la calidad estará garantiza. Pero, la pregunta del millón es: ¿cubrimos cosas obvias o que nosotros creemos, o estamos seguros de que funcionan?
Habitualmente, lo que sucece es que estas cosas “obvias” no se comprueban, las damos por hechas y por validadas. Nuestra “humanidad” nos dice que no son necesario validarlas, nuestro cerebro nos ahorra tiempo, que no tenemos y confiamos en ello, en que funcionará e irá bien.
Cuando estamos tirando lineas de código y nos liamos a realizar test unitarios, pensamos en un montón de cosas que son demasiado obvias para probar y nos centramos en los casos complejos. Esto nos lleva a que si falla algo obvio, el tiempo de encontrar el fallo y solucionarlo nos llevará más tiempo, porque claro, lo obvio...no debería de fallar.
La estrategia a seguir es muy sencilla. Todo código tiene, siempre, una serie de secciones que se van repitiendo, y que, por ejemplo, son: un login, un botón acceder, un menú de secciones, una sección de contacto...un número limitado de módulos que suelen existir en todo proyecto y debemos de tener categorizados, ya que, habitualmente, los códigos pueden reutilizarse.
Si tenemos una categorización de módulos, podemos tener una serie de test ya creados que prueben estos módulos “obvios”, y que simplemente, tendremos que ajustarlos al proyecto que aplique y lanzarlo para ver su resultado.
Si contamos con una batería de test genérica que pueda validar una serie de módulos que suelen utilizarse habitualmente, lo único que tenemos que hacer, es ampliar esta batería con los casos diferenciales y que no son obvios y tendríamos una gran cantidad de código ya probado y garantizado para que las personas de QA puedan validarlo y darle el OK definitivo.
Lo más importante, siempre, es tener estrategias de pruebas a nivel de código, que nos mantengan una exigencia y una calidad en nuestro trabajo y que junto a las nuevas formas de trabajo en entornos DevOps, con las herramientas de análisis de código, como SonarQube, podamos mantener unos estándares adecuados en el código que generamos.
0 Comentarios