Pruebas en el software

Notas del capítulo 11 Testing overview del libro Software Engineering at Google.

Las pruebas hacen parte del desarrollo de software de calida y generan varias ventajas

• Encontrar errores en el código : debido a que no todo sale como se planea siempre
• La refactorización del código : después de hacer el refactor si la funcionalidad no cambia las pruebas deberían seguir pasando
• Abrazar el cambio : hacer cambios sabiendo que no dañamos algo previo
• Generar tiempos de mercado más rápidos : aunque hacer pruebas toma tiempo, este tiempo en proporción a la longitud del proyecto lo hace más robusto
• Generan conocimiento colectivo : el conocimiento de la persona que realizó el codigo sirve como conocimiento colectivo para los futuros desarrolladores, de cómo debe funcionar una parte del sistema e incluso como documentación en algunos casos
  

Especialmente las pruebas automatizadas tiene muchísimo valor por que sin necesidad de que una persona ponga tiempo extra cada vez que se realiza un cambio estas pueden ser recorridas con facilidad , se comenta que en Google en el pasado se le tenía mucha fe a las mente brillantes que hacían las cosas funcionar hasta que los resultados de hacer muchas pruebas y el cambio cultural que se generó en la compañía los llevó a darle una importancia más alta a la pruebas.

El resultado más importante que se comenta de datos en el capítulo es que tienen un sistema llamado GWS encargado de las búsquedas que cada vez que hacían un cambio el 80% de las veces les tocaba devolverlo porque rompían algo, pero luego de una años con una política de pruebas más estricta esta cifra fue reducida a la mitad (esto más relevante aun por que este sistema sufrió cambios importantes y constantes)

Por el cambio cultural se generaron varios escenarios para impulsar a los ingenieros a realizar pruebas entre ellos una inducción a las personas nuevas sobre las virtudes de las pruebas, panfletos sobre pruebas en los baños y competencias entre los equipos en relación a la madurez de estos en el tema de pruebas.

En google es interesante que dividen las pruebas basadas en dos clasificaciones una de estas son las clásicas pruebas unitarias, pruebas de integración y pruebas funcionales. pero la otra hace relación al tamaño de las pruebas vinculado a los recursos que consume esto lo hacen por que es mucho mejor tener pruebas pequeñas que consuman pocos recursos(en tiempo de ejecución, llamados de red, I/O, hilos) que permiten ser recorridas a menudo y rápidamente.

Es tanto así que recomiendan a los equipos tener 80% pruebas unitarias, 15% pruebas de integración y 5% pruebas funcionales, esto es por que las pruebas unitarias pueden ser corridas más a menudo,más rápido y es más fácil corregir los errores si se daña una de estas disminuyendo así el tiempo que los ingenieros deben pasar debugeando código. Por otro lado, tener muchas pruebas de integración puede llevar fácilmente a que el tiempo que toman las pruebas en correr sea demasiado alto y que se deba pasar una mayor cantidad de tiempo debugeando para corregir los errores que se generen en esta pruebas.

hay dos tipos de test problemáticos que google a encontrado los flaky test que son test no deterministas que de repente sin motivo se rompen y/o aveces funcionan al final google cree que estos deben ser arreglados por que afectan negativamente la confianza del equipo en la colección de pruebas y; los brittle test que son test que se rompen con facilidad incluso cuando se toca algo que no debería estar relacionado para estos recomiendan evitar el uso de mocks, probar solamente interfaces públicas que varios equipos usan y validar las entradas y las salidas de los sistemas no cómo estos interaccionan para corregirlos.

Una suite de test robusta puede indicar un diseño robusto del sistema y lo contrario también es cierto al final los test solo deberían cambiar cuando se genera un cambio en una funcionalidad, nuevas funcionalidades y/o bugs deberían crear nuevos test.