Cuando usamos funciones de bibliotecas externas, asumimos que se comportarán de cierta manera. Sin embargo, esas suposiciones pueden ser incorrectas y, si no se prueban exhaustivamente, pueden introducir riesgos innecesarios en el código. En este artículo exploramos cómo ciertos estados, nos enseñan a validar nuestras suposiciones y mejorar la calidad de nuestras pruebas.
Lecciones Aprendidas
Una de las principales razones para escribir pruebas automáticas es garantizar que los componentes se comporten según lo esperado, incluso en los casos más extremos. Esto incluye:
- Caminos felices (lo que esperamos que funcione).
- Caminos tristes (errores esperados).
- Caminos inválidos (casos que no deberían ser válidos).
Al hacer tests unitarios se evalúan todos los escenarios posibles que pueden surgir al interactuar con la biblioteca URLSession. Estos son los resultados representables:
| Data | Response | Error | Estado Representable |
| Nil | Nil | Nil | Invalido |
| Nil | URLResponse | Nil | Invalido |
| Nil | HTTPURLResponse | Nil | |
| Value | Nil | Nil | Invalido |
| Value | Nil | Value | Invalido |
| Nil | URLResponse | Value | Invalido |
| Nil | HTTPURLResponse | Value | Invalido |
| Value | URLResponse | Value | Invalido |
| Value | HTTPURLResponse | Value | Invalido |
| Value | URLResponse | Nil | Invalido |
| Value | HTTPURLResponse | Nil | Valido |
| Nil | Nil | Value | Valido |
URLSession.Descubrimientos Inesperados
Durante el desarrollo, paso algo, URLSession reemplazaba datos nil con una instancia vacía de Data (0 bytes) cuando la respuesta era un HTTPURLResponse válido. Este comportamiento, inicialmente no documentado, enseña una valiosa lección: probar nuestras suposiciones sobre bibliotecas de terceros.
Al identificar este comportamiento inesperado, lo que debemos hacer es mover el caso válido a un test separado, haciendo nuestras pruebas más precisas y fáciles de interpretar.
Gestionar el Riesgo con Pruebas Exhaustivas
Probar todas las rutas representables no solo mejora la resiliencia del código, sino que también nos prepara para futuros cambios en las bibliotecas. Por ejemplo, en iOS 14, el comportamiento de URLSession cambió al reemplazar errores con una nueva instancia que incluye información adicional en el diccionario userInfo. Detectar estos cambios a tiempo nos permite actualizar nuestras pruebas y evitar sorpresas en producción.
Conclusión
Escribir pruebas no es solo una tarea técnica; es una inversión en la calidad y mantenibilidad de tu código. Validar nuestras suposiciones y probar exhaustivamente todas las rutas posibles garantiza que nuestros componentes sean confiables y predecibles, incluso cuando dependemos de bibliotecas externas.
Adopta estas lecciones y refactoriza tus pruebas para maximizar su valor. No solo estarás escribiendo mejores tests, sino que también aprenderás más sobre las herramientas y bibliotecas que utilizas a diario.
Referencias
URLRequest
https://developer.apple.com/documentation/foundation/urlrequestURLResponse
https://developer.apple.com/documentation/foundation/urlresponseHTTPURLResponsehttps://developer.apple.com/documentation/foundation/httpurlresponseXCTestCasereference
https://developer.apple.com/documentation/xctest/xctestcase