Home > Desarrollo, Testing > Errores comunes al hacer pruebas de software de nuestro código

Errores comunes al hacer pruebas de software de nuestro código

Los desarrolladores cada vez estamos más concienciados de la importancia de las pruebas de software. Pero no podemos pasar por alto la calidad de estas pruebas, ya que podemos caer en errores no contemplados sin darnos cuenta. No es suficiente con hacer un par de tests y pensar que todo está todo correcto porque nuestra aplicación pasa esos tests, es importante pararse a pensar si cómo hemos planteado las pruebas es la forma correcta para detectar errores reales del código.

A continuación se mostrarán algunos errores comunes a la hora de hacer tests extraídos de un interesante post en Dzone sobre testing.

Test unitarios

Es sencillo probar una clase de utilidad con sólo llamar a todos los métodos de la clases, pasando valores y comprobando si el resultado es el esperado. Aquí caemos en el error de hacer pruebas del estilo: 1+1=2 y 2+1=3. Pero no hacemos, por ejemplo, pruebas de casos limites como cuando los valores son null o si se provoca una excepción, estas quedan muchas veces fuera de nuestras pruebas.

El uso de Mocks

Si nos encontramos en el caso de que queremos probar la capa de servicio, el DAO lo solemos simular manualmente. Un terrible error que puede llevar a confusiones en los test, para hacer este trabajo deberíamos usar un Mock que nos permite hacer pruebas más cercanas a la realidad para eso están creados.

Podemos elegir entre varios framework como Mockito o EasyMock, entre los más conocidos. Pero tener cuidado de elegir el correcto, el exceso de simplicidad o, por el contrario, el de complejidad nos puede traer algún que otro quebradero de cabeza.

Test de integración

En los test de integración cubrimos las diferentes piezas que trabajan en conjunción de nuestra aplicación. Una de ellas es la capa DAO, con la que intentamos validar el funcionamiento conjunto con los parámetros de entrada, las conexiones de base de datos y si sus respectivas queries son las correctas.

Solemos caer en el error de no usar datos que se correspondan con los reales, por lo que nuestros test pueden ser trucados con parámetros de entrada que reciban de la base datos información errónea o incompleta haciendo malabarismos manualmente para comprobar que el test es correcto. También es importante poder cargar datos de tal forma que podamos volver de nuevo al estado inicial.

Test funcionales

Después de probar buena parte de nuestro código técnicamente, no debemos olvidar los bugs funcionales. A través de los test funcionales podemos detectar esos errores. Aunque tengamos la percepción de que son difíciles y costosos de mantener más lo es hacer eso manualmente.

Selenium es una gran framework para grabar este tipo de test con el navegador, aunque caemos en el error de sólo hacerlos ahí. Selenium trackea los componentes HTML, por lo que si cambiamos algo de la página romperemos el test inmediatamente y no necesariamente es porque esté mal. Una opción más robusta es usar API WebDriver que proporcionar una interfaz de programación alternativa para testear con una API orientada a objetos.

Otra cosa que tenemos que tener en cuenta es dejar también en los test cada elemento o dato en su estado inicial. Si en un test hacemos login, debemos recordar cerrar sesión para no interferir en posteriores test o al contrario.

Artículo sacado de GenbetaDev

Advertisements
Categories: Desarrollo, Testing Tags: ,
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: