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.
No soy un experto en realizar tests, pero como muchos desarrolladores estoy comenzando con TDD por eso quiero compartir con vosotros algunos errores comunes a la hora de hacer tests que extraído de un interesante post en Dzone sobre testing. Es un breve repaso en cada ámbito que podéis completar en los comentarios. Hablaremos sobre pruebas unitarias, mocks, test de integración, test funcionales y BDD.
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.
Vía | Javacodegeek
En Genbeta Dev Respuestas | ¿Qué herramientas utilizas para automatizar las pruebas de software?
