3 Tips al realizar pruebas unitarias de Cloud Functions

Explico los problemas que me he encontrado al probar las cloud functions

hace 20 días   •   2 min de lectura

Por Andrés Tuñón

Este artículo será estilo bitácora, corto y enfocado en unos problemas que me han surgido al probar las Cloud Functions.

Siempre debes inicializar el SDK de firebase al principio

Cuando modifiqué un cloud function responsable de escuchar firestore, es decir de ejecutarse cuando la base de datos cambia, coloqué la inicialización de firestore dentro de una condicional.

condicionales
condicionales

No lo pueden ver en el código anterior, pero fue justo antes de obtener la referencia de streamers, justo porque ahí es donde lo necesito.

Luego al probar intente usar 'firebase-functions-test', la librería oficial que ayuda a reemplazar el sdk del lado de testing (cosa que no comprendía del todo).

El problema surge cuando usas  'firebase-functions-test' y aún no inicializas firebase del lado de la implementación; por esta razón, si en alguna parte del código necesitas usar firebase es mejor que lo hagas al principio.

Además, de que los SDK se suelen inicializar previamente por simple convención.

Cuidado con las pruebas asíncronas

Estuve por un buen rato verificando que el método de resume se ejecutara, pero no fue hasta que vi que llegaba al breakpoint en la implementación después de que la prueba había terminado.

Todo porque no le había puesto await al wrapped (no era consciente que mi cloud function era asíncrono incluso después de wrappearla).

Separa el código

Dependo de una librería que consulta jobs y todo lo concerniente a esa dependencia la separé en una clase.

mockeando mi clase wrapper
mockeando mi clase wrapper

Esto me ayudo muchísimo al probar, porque solo debo mockear las dependencias, los métodos que voy a usar y ese código lo escribí yo; no debo mockear código raro y solo lo que voy a necesitar. Si no fuera así, debería mockear tooooda la librería.

Corre la voz

Sigue leyendo