Testing de software
Comprobar que el software hace lo que debe, sobre todo con código que prueba código.
El testing de software es todo lo que se hace para saber si un programa funciona antes de que lo descubran sus usuarios. Una parte es manual: una persona recorre la app buscando problemas. La mayor parte, en los equipos de hoy, son tests automatizados: programas chicos que llaman al código real con datos conocidos y revisan el resultado. Un test puede decir: "total([10, 5]) tiene que devolver 15". Si más adelante alguien rompe eso, el test falla y le avisa.
Los tests vienen en capas. Los tests unitarios prueban una pieza chica, como una sola función, en milisegundos. Los tests de integración prueban que las piezas funcionen juntas, por ejemplo el código con una base de datos real. Los tests end-to-end manejan la app entera como lo haría un usuario, abriendo un navegador y haciendo clic; son los más realistas pero también los más lentos y frágiles. El consejo habitual, llamado pirámide de tests, es tener muchos unitarios, menos de integración y unos pocos end-to-end.
El valor principal es animarse a cambiar cosas. Una buena suite de tests corre sola en cada cambio dentro del pipeline de CI y atrapa regresiones, funciones viejas rotas por código nuevo, en minutos. Pero los tests no prueban que todo esté bien: solo revisan los casos que a alguien se le ocurrieron. Como dijo el científico de la computación Edsger Dijkstra, el testing puede mostrar que hay bugs, nunca que no los hay.
Para quedarse
- Los tests automatizados son código que corre tu código y revisa los resultados.
- Los tests unitarios, de integración y end-to-end cambian velocidad por realismo.
- Corren en cada cambio, así que las funciones rotas se detectan temprano.
- Que pasen los tests significa que los casos probados andan, no que no haya bugs.
Para seguir leyendo
- Pruebas de software en Wikipedia
- Prueba unitaria en Wikipedia
- The Practical Test Pyramid (martinfowler.com, en inglés)