Probando ando

Una vez que ya tienes tu software medianamente funcional hay una parte que quizá puedes pasar por alto y cuando tengas que liberar la primera versión te lamentes por no haber hecho las cosas de la manera correcta, sí, estoy hablando del testing. O las pruebas cool para los amigos. Probar las cosas es una muy buena forma de saber si las cosas funcionan de la manera en la que esperamos pero a veces esto no es suficiente para hacer buen software, mucho menos si el nuestro está orientado a objetos.

Prueba antes de avanzar

via GIPHY

Una vez que el paradigma orientado a objetos cubrió gran parte del panorama de desarrollo surgieron grandes interrogantes alrededor de el y uno de ellos fue la parte del testing y no era para menos, al ser las clases una de sus características más interesantes mucha gente comenzó a preguntarse cómo es que se iban a probar estas por separado cuando muchas de estas formaran parte de una funcionalidad más grande.

Otra de las cosas que también comenzó a hacer algo de alboroto fue la encapsulación: si bien esta es gran avance sobre todo en materia de seguridad frente al usuario no olvidemos que también oculta mucha información relevante para las técnicas tradicionales de testing y bueno, para qué empezamos a hablar de la herencia... El desastre estaba servido, ¿de qué manera se actuó? Bueno, es una historia corta pero con muchos conceptos nuevos.

Características cool nunca incool

via GIPHY

Al tener varias características que diferenciaban al paradigma Orientado a Objetos se necesitaron crear a su vez técnicas que suplieran las nuevas necesidades de testing y las siguientes son:

• Method Testing: Las pruebas de siempre, una vez que el método funciona entonces el programador debe de asegurarse que cubre todos los casos bases y que el método no haga cosas que no se supone que debe hacer. Aún y cuando esta técnica parezca ser suficiente tiene un punto débil bastante notorio: el sesgo del programador.
• Class testing: Se parece bastante al Method Testing pero este va con esteroides pues se deben probar, además de los métodos y constructores de una clase, el comportamiento de toda la clase y como responde esta a la interacción con otras clases. Aquí es donde todo se empieza a torcer pues conceptos como herencia, polimorfismo y encapsulación nos harán la vida de cuadritos.
• Integration Testing: Una vez que tengas varias clases que correspondan a una mismo requerimiento entonces lo mejor que puedes hacer es comenzar a verlo todo como un conjunto. Esta técnica incluye el enviar mensajes entre clases y métodos para observar como es el comportamiento del conjunto y revisar si todo va en orden.
• System Testing: ¿Ya tienes casi todas las características y todo parece ir en orden? Ja! Iluso. Lo que sigue es probar todo tu sistema y revisar como se comporta en cuanto a errores y seguridad, también debes de revisar qué es lo que pasa cuando haya una sobrecarga y observar si su desempeño es el óptimo dependiendo la tarea que esté haciendo. 
• Regresion Testing: Cuando agregues una característica asegúrate no estar rompiendo las cosas que ya están funcionando bien, eso es más o menos de lo que va esta técnica. Si alguna nueva funcionalidad agrega errores a tu código es mejor replantearlo dos veces y revisar qué es lo que está pasando.

Qué difícil se me hace

via GIPHY

Sí, sabemos que probar cosas es tedioso y más cuando tienes a un jefe detrás de ti presionándote para que todas las cosas vayan bien, sin embargo, esto es absolutamente necesario y más si estás desarrollando bajo el paradigma Orientado a Objetos, ¿por qué?  Bueno, ya te lo hemos dicho 3 veces en este post pero si te quedan algunas dudas vamos a repasarlas aquí mismo:

• Polimorfismo: ¿Recuerdas cuando esta característica te daba dolores de cabeza para entenderla? Bueno, ahora te dará dolores de cabeza pero para probar funcionalidad. Imagina que tengas una de las múltiples formas que tenga alguna de tus clases tenga un error, ¿cuál de todas será? Suerte buscando tu error.
• Encapsulación: Si, ocultar información y romper tus problemas en muchas partes está muy bien pero al ocultar información también estás escondiendo algunos errores en el proceso. 
• Herencia: ¿Y si la clase de la que heredas tiene algún error? Bueno, ahora tienes múltiples errores y no sólo uno. Espero todo esté bien en casa.

El paradigma Orientado a Objetos llegó para quedarse y aún le quedan muchísimos años más así que más vale que te acostumbres a usar este tipo de tećnicas cuando estés revisando los posibles errores de tu software. ¡Ah! Una última cosa, toda la información de este post fue sacado de este artículo escrito por Haryana Gurgaon, así que si quieres saber más de primera mano te recomendaría ir a leer su artículo que no tiene ningún desperdicio.