Pruebas Automatizadas ¿Por qué tengo que probar?

En algunos momentos siento que cuando toco el código por que necesito arreglar o mejorar algo termino rompiendo o dañando todo lo que ya estaba estable y en muchos casos me doy cuenta muy tarde, y si está el codigo en producción es muy grave.

¿Por qué tengo que probar? !Mi código funciona perfectamente!.

Una pregunta que me he repetido todos estos años como programador y a lo largo de mi carrera nunca nadie me ha enseñado cómo, o por qué, debería probar mi código y nunca he conocido a un solo programador que pueda codificar perfectamente. No creo que exista tal persona, y mucho menos tomando en cuenta que los tiempos de de entrega son muy cortos o existen malas planificaciones.

Mi respuesta a aquellos que me quieran decir que su código es perfecto les pregunto: ¿Cómo sabes que tu código funciona perfectamente. ¿Lo has probado? ¿Puedes probarlo ahora y decirme que funciona perfectamente?

Cuatro simples consejos para realizar las pruebas

  1. Desarrollar pruebas de el caso más común con todas la varientes que pueda. Esto nos dirá cuando ese código se rompe después de hacer algún cambio (que es, en mi opinión, el mayor beneficio de las pruebas unitarias).
  2. Hacer pruebas de casos borde de un código complejo que podamos creer que tendrá errores, por que esos casos siempre nos dará pelea.
  3. Siempre que encuentremos un error debemos escribir un caso de prueba para cubrirlo antes de comenzar a arreglarlo
  4. Siemore que tengamos tiempo libre desarrollemos pruebas de código menos crítico que pensamos que es muy simple para que pueda fallar.

Es difícil saber por dónde empezar cuando se es nuevo en el mundo de las pruebas de software. Hay muchos tipos diferentes de pruebas de software. Yo recomiendo empezar con pruebas unitarias, pruebas de integración y pruebas de regresión.

!Pero existe otras pruebas!

  • Test de aceptación
  • Pruebas alfa
  • Prueba beta
  • Prueba de caja negra
  • Pruebas comparativas
  • Pruebas de compatibilidad
  • Pruebas de extremo a extremo
  • Pruebas funcionales
  • Prueba de integración incremental
  • Prueba de instalación / desinstalación
  • Pruebas de integración
  • Prueba de carga
  • Pruebas de rendimiento
  • Pruebas de recuperación
  • Pruebas de regresión
  • Pruebas de sanidad
  • Pruebas de seguridad
  • Pruebas de estrés
  • Prueba del sistema
  • Examen de la unidad
  • Pruebas de usabilidad
  • Prueba de caja blanca

Prueba unitarias en Java con JUnit

Junit nos asegura que cada unidad funciona correctamente y eficientemente por separado. Además de verificar que el código hace lo que tiene que hacer.

Vemos un pequeño ejemplo,  desarrollamos una calculadora que suma dos números, si enviamos como parametro 1, 2 esperamos que la respuesta sea 3 siertamente es una formula sencilla (1+2) = 3

 

Si quieres conocer más de JUnit puedes leer la documentación desde su web

Las pruebas aumentan el tiempo de desarrollo

Realmente escribir pruebas ahorra mucho tiempo y muchos dolores de cabeza a largo plazo. Ser capaz de repetir las pruebas con el clic del ratón y confirmar que todo funciona como se espera le da la confianza para enviar el software a la producción. Si algo sale mal, simplemente puede ejecutar sus pruebas para ayudar a descubrir el origen del error.

El truco es hacer que sea una parte de su flujo de trabajo de desarrollo de software convirtiendose en un hábito.

Hay un montón de metodologías de pruebas de software. Como desarrollador de software no necesitamos utilizarlas todas pero si por lo menos las pruebas unitarias

Comments are closed.