Testing 101: Una introducción a las pruebas de software

Desde hace un tiempo suelo usar el valor 101 (ciento uno) para hablar de forma básica de cualquier tema. Seguramente os preguntaréis, ¿por qué 101? Bueno, el 101 se usa para la primera clase del primer curso de cualquier asignatura que se estudia en los Estados Unidos; así que es, por así decirlo, una introducción a una asignatura.

Por ello, en este post de Testing 101 vamos a hacer una introducción al testing o pruebas de software.

¿Qué es el testing?

El testing o pruebas de software es, básicamente, un proceso por el que se comprueba que algo funciona como esperamos que lo haga. En el mundo del desarrollo de software se trata de probar que una pieza de nuestro código funciona correctamente.

Metodologías y tipos de pruebas de software

Para ir un paso más allá, debemos saber dos cosas:

1. Existen dos metodologías muy diferenciadas dentro del testing: los métodos de caja negra y caja blanca.
2. Por otra parte, existen dos grupos de testing: los tests funcionales y los tests no funcionales.

Además de esto, también debemos saber que hay diferentes formas de hacer testing, pero de esto hablaremos más adelante .

Pruebas de caja negra y caja blanca

Aunque el nombre es un tanto extraño ya que hablamos de algo técnico, esto de las cajas de colores es bastante sencillo de entender.

La diferencia principal entre ambas pruebas es que:

1. Las de caja blanca prueban la estructura del código fuente, es decir, se prueba lo que hace realmente el código y no lo que debería hacer. Esto hace que las pruebas de caja blanca estén muy ligadas al código, tanto que para realizarlas es necesario escribir el código primero y después realizar los tests.
2. Las de caja negra prueban qué debe hacer el código fuente. Se pueden realizar antes de que esté el código escrito porque sabemos de antemano que una entrada debe tener una salida concreta. Cómo lo resuelva el código o las operaciones que tenga que hacer, no nos importa tanto.

Pruebas funcionales y no funcionales

Por otra parte, tenemos las pruebas funcionales y las no funcionales. Estos dos tipos de pruebas tienen unas diferencias bastante sutiles que explico a continuación:

• Los test funcionales se realizan para garantizar que las funcionalidades del software se comportan como se esperaba y validan el software con respecto a la especificación del mismo.
• Las pruebas no funcionales, en cambio, son como las funcionales pero se centran más en el rendimiento, la usabilidad, la escalabilidad o la fiabilidad.

Estos tests a su vez se dividen en varios tipos:

• Para los test funcionales se suelen hacer test unitarios, que prueban cada una de las partes del código de forma independiente, y las pruebas de integración, que prueban el comportamiento de varias partes del código que funcionan como un grupo.
• En cuanto a las pruebas no funcionales, lo que se suele hacer son pruebas de carga, ya que estos tipos de test son perfectos para evaluar la escalabilidad de una aplicación, o para ver el rendimiento que podemos tener cuando se hace un uso intensivo de la misma.

Triángulo del testing

Ahora que sabemos que hay varios tipos de tests, tenemos que determinar cuántos debemos hacer. La respuesta es sencilla: cuantos más, mejor.

Lo importante aquí es saber qué tipos de test debemos realizar y cuántos son lo óptimo. Para ello podemos observar la “Pirámide del Testing”, que es una forma de representar que lo mejor para nuestras aplicaciones es llevar a cabo más cantidad de test unitarios, ya que son lo más rápidos de ejecutar, seguido de unos cuantos tests de integración, algo más lentos pero muy útiles para ver que todo está bien conectado y, por último, pero no menos importante, unos pocos test de extremo a extremo, manuales, etc.

Se ve más claro en esta imagen:

Métodos para la realización de tests

Como en todo oficio, en el testing también hay varias formas de hacer las cosas. No quiere decir que una forma sea mejor que otra, simplemente existe un compendio de buenas prácticas que nos aconseja cómo hacer las cosas de manera óptima.

En el caso del testing, cuando empezamos a hacer nuestros primeros tests, lo primero que hacemos es escribir en el código, por ejemplo, una función que recibe dos números nos devuelve el cociente de la división entre ambos. Entonces, una vez hecho esto, hacemos un test que pruebe que nuestra función hace la división de forma correcta.

Esta forma de hacer testing no suele ser la más indicada; yo siempre he dicho que si escribo el código primero, de manera inconsciente no suelo probar aquello que sé que puede fallar. Por seguir con el ejemplo, seguramente no has caído en que si a tu función que te devuelve el cociente de la división le pasas como segundo argumento un 0, va provocar que la función falle, pues no puedes dividir entre 0. Quizás lo sabías, quizás no, pero como se suele decir: hecha la ley, hecha la trampa, y esto nos pasa de forma inconsciente.

Como respuesta a esto surge una práctica que se llama TDD (Test Driven Development), o Desarrollo dirigido por tests. Esta práctica nos indica que primero se escribe el test y luego el código que hace que ese test sea válido. Después se refactoriza el código, es decir, se mejora el código para que cumpla ese conjunto de buenas prácticas.

¿Es mejor seguir esta práctica en lugar de escribir código y luego hacer el test? Los expertos dicen que sí, pero esta práctica es bastante compleja incluso para los que llevamos mucho tiempo en este mundo. Aún así, hay mucha bibliografía, y con práctica podemos usar el TDD de forma fluida en nuestro día a día como desarrolladores.

Si estás empezando en el mundo del desarrollo, te aconsejo que primero entiendas los tipos de tests, que experimentes con ellos y entiendas bien para qué sirve cada uno de ellos. Cuando tengas soltura, dale una oportunidad a TDD; así verás las diferencias y las ventajas que tiene uno frente al otro.