Aprende a detectar malos tests de software

Como empresa especializada en qa testing sabemos que un mal test de software puede, en el mejor de los casos, no probar nada y en el peor, romper un buen código.

Por tanto, es fundamental evitarlos.

¿Qué es un test de software malo? Aquí hay algunos ejemplos.

El test de software de la nada

El ejemplo más fácil que podemos encontrar de un test malo es el test de software que no prueba nada.

Lo sé, esto parece un poco inverosímil, pero en realidad ocurre más a menudo de lo que crees.

Tomemos por ejemplo este test de inicio de sesión:

describe('Authentication', () => {
    it('can successfully log in a user', () => {
        browser.url("https://mypage.com/login");
        $("#username").setValue("Username");
        $("#password").setValue("Password!1234");
        %("#submit-btn").click();
    });
});

Este test de software se asegura de que los elementos del formulario funcionan correctamente, pero no comprueba lo más importante para el escenario: que el inicio de sesión se complete con éxito.

Puede parecer obvio aquí, pero una vez que empiezas a mover el código en funciones reutilizables, puedes encontrarte con problemas. Por ejemplo, cuando se comprueba una función en un determinado escenario pero no es comprobada en otro diferente:

describe('Authentication', () => {
    it('can successfully log in a user', () => {
        userLogin(data["successful"]);
        checkLogin(data["successful"]);
    });

    // Some test developed a couple months later
    it('can successfully log in as an admin', () => {
        userLogin(data["admin"]);
        // forget to call checkLogin because we asume userLogin already does that
        checkAdminEmailSent();
    });

});

Aunque este ejemplo es muy simplista, es fácil imaginar que puede suceder en un proyecto largo.

Hay básicamente tres soluciones para evitar que esto ocurra:

1. Comprobar siempre explícitamente dentro de la definición del test de software

2. Todas las funciones deben comprobarse a sí mismas

3. Pruebas de mutación

El primer enfoque es sencillo: asumimos que cualquier comprobación que no se mencione explícitamente en la definición del test de software no existe, y por lo tanto tenemos que indicarla allí. Esto es útil porque hace que lo que estamos probando esté claramente descrito en la definición.

El segundo enfoque es más complicado: hacer que cada función se compruebe a sí misma. Esto requiere repensar algunas de las funciones, pero si se hace bien garantiza que todo lo que se hace cumple con las expectativas.

El último enfoque requiere una herramienta externa, como Stryker, y es, quizás, el más completo. Haciendo cambios en nuestro código y asegurándonos de que falla, podemos estar bastante seguros de que nuestras pruebas tienen sentido. La otra cara de la moneda es que este acercamiento es muy costoso en tiempo.

En definitiva, asegúrate de que cada test de software realmente comprueba lo que necesitas que compruebe.

El test de software ilegible

Este tipo de test de software "funciona", del mismo modo en que también se puede comer un filete con una cuchara.

La mayoría de las veces todo va bien hasta que alguien necesita cambiarlo, refactorizarlo o ampliarlo, momento en el que ese alguien perderá más de 10 horas de su vida tratando de darle sentido al desorden.

Este tipo de test de software suele darse como resultado de uno de estos tres casos:

1. Programación cowboy

2. Programación de fuerza bruta

3. Iteraciones múltiples

El primer caso es en realidad el menos común: alguien acaba de escribir un código malo, sin seguir ningún tipo de principios de legibilidad u ordenación. Ocurre sobre todo con programadores inexpertos que no revisan su código o en proyectos personales que en el futuro acaban siendo un trabajo en equipo. El remedio es muy sencillo: aplicar revisiones de código y recordar que "no entiendo este código" es siempre una crítica válida.

El segundo caso es más común: alguien escribió un buen código y no funcionó. Luego lo modificaron ligeramente y siguió sin funcionar. Lo modificaron más y más y más hasta que finalmente funcionó como estaba previsto. Y entonces se olvidaron de revisarlo, sobre todo porque estaban demasiado ocupados haciendo un baile de la victoria. El remedio es, de nuevo, sencillo: ¡revisiones del código!

El tercer caso es probablemente la forma en que se producen la mayoría de los test ilegibles. Se hace un test para cubrir un caso X, y es precioso. Dos semanas más tarde, la funcionalidad cambia ligeramente y se retoca. Un mes más tarde, hay una gran reelaboración de la aplicación que hace que el caso de uso se comporte de manera muy diferente. Al final, el test es un desastre. Una vez más, es importante que se revise el código, pero para evitar este problema, la revisión también debería centrarse en el código que lo rodea para asegurarse de que sigue siendo legible.

Así que las revisiones de código son el arma principal contra los problemas de legibilidad y siempre debemos esforzarnos por revisar mejor el código.

Estos son algunos de los escollos con los que nos podemos encontrar a la hora de crear tests de software y si nos preocupamos por evitarlos, todos nos convertiremos en mejores desarrolladores.

Conoce a Redsauce y descubre estos consejos y muchos más en neustro ebook gratuito.