Evaluar mejoras del entorno de test unitarios e integración

[giodelabarrera]

Actualmente usamos sui-test para tests unitarios e integración y este paquete utiliza internamente:

• Mocha como framework de test
• Chai como libreria de asersiones
• Karma como test runner

Contexto

En el cluster de profesionales de Real Estate hemos estado trabajando en una épica de incrementar nuestra confianza de tests de componentes a nivel unitario y de integración.
Hemos avanzado mucho y lo continuamos haciendo pero queríamos también compartir algunas desventajas que nos hemos encontrado en el camino y que creemos que podriaís tenerlas y que podrían ser valoradas.

Desventajas

Único sandbox para todos los tests

• Karma levanta un servidor web en un puerto especifico y en una url index.html y lanza allí toda la suite de testing. Es perfecto en el sentido de que nuestra suite de tests son lanzados sobre un navegador real, pero por el otro lado estas se ejecutan en un único sandbox y cuando en uno de sus tests trabajamos con Web APIs (DOM, Session Storage, etc) el entorno puede quedar mutado provocando side effects en el resto de tests. Por ejemplo, si renderizamos componentes que trabajan con modales, storage, cookies, history.

Contexto de errores

• Cuando obtenemos un error del test, la terminal pinta todo el DOM del componente montado y muchas veces es cortado. Podemos llegar a ver el error del test fallido haciendo scroll hasta ver el mensaje de color rojo pero podría ser más enriquecido el feedback como los framework de testing actuales.

• Debido a esto junto con el punto anterior “Único sandbox para todos los tests” en nuestro cluster tuvimos un error que tardamos en localizar debido a que había un componente que hacia una llamada a un endpoint securizado y al no estar autenticados nos provocaba un redirect al login sacándonos de la URL de Karma en donde ejecuta toda la suite de tests dejando de ejecutar el resto de tests pendientes y solo mostrándonos que uno de nuestros tests había provocado un reload de la pagina.

Limitación de mocking

• Somos conscientes del principio: The more your tests resemble the way your software is used, the more confidence they can give you pero hay veces de que necesitamos mockear a nivel de integración.
  Actualmente usamos sinon para resolver esta necesidad, pero no podemos mockear módulos importados, por ejemplo módulos como custom hooks para casos donde nos interesa manipular el resultado como size viewport, feature flags, A/B tests, lazy loads con intersection observer.

Velocidad

• Tal vez nos equivoquemos pero consideramos que nuestro framework de test podría ser más rápido en la carga de la suites de todo el framework (building), ademas de poder tener la opción de ejecutar todos nuestros tests en paralelo o solo los tests de los ficheros modificados (uncommitted files) cuando trabajamos en desarrollo.

A tener en cuenta

Issue Karma + MSW

• Con MSW tuvimos un caso que al intentar sobreescribir un handler en el test no nos hace matching, pero si ejecutamos ese test con un setTimeout si nos pasa, siendo nuestra teoría que es por el tiempo de asincronia de handlers, servidor de Karma y uso de MSW mediante su proxy. Quizás esté relacionado con una issue existente:
  - Karma example is unstable mswjs/examples#56
  - MSW randomly fails to mock GET request while running tests with karma / jasmine mswjs/msw#854
• En algunas ocasiones no nos hace el match de endpoints que están definidos en el directorio /mocks mostrandonos warnings por consola

Acoplamiento Webpack

• Desconocemos si Karma habilitara la API para migrar de Webpack a otro bundlerizador o deberemos de usar otro loader para el transpilamiento de ficheros, cosa que tengamoslo en el radar ya que implicará un esfuerzo por si se quiere migrar a otro como swc .

Infrastructura

• Probablemente podríamos ahorrarnos el uso de un navegador real en niveles de test unit e integration corriendo nuestros tests en node para javascript puro o un fake DOM para componentes y hacer el uso de un navegador real en un nivel de test e2e

Cabe recalcar que ademas en el cluster de profesionales de Real Estate hemos dejado de utilizar la suite de testing levantando la demo por Web APIs compartido (DOM, Window) entre demo de componente y componente montado del test ya que estos nos provocaban flaky tests, es decir siempre ejecutamos en modo headless.

Estamos muy interesados en saber si teneís estos mismos problemas y nos gustaría saber qué opiniones teneís sobre los mejores modos de avanzar.

[xaviermariaconejo]

Gran explicación. Estamos teniendo todos estos pains en nuestro Repositorio. La experiencia de desarrollo muchas veces acaba siendo pésima, sinceramente.

Por otra parte, estos pains también acaban afectando al usuario, ya que en más de una ocasión hemos tenido la pipeline bloqueada sin poder hacer subidas, y teniendo que dedicar MUCHO tiempo a arreglar alguno de estos problemas, lo que nos impide entregar mejoras al usuario final.

Además, que en varias ocasiones, debido a la urgencia de alguna entrega de alguna feature, hemos tenido que tener los tests deshabilitados para poder seguir desarrollando producto, ya que el único pain estaba en los tests...

La verdad es que me muero de ganas de migrar a otra tecnología que solucione estos problemas, en mi opinion con Jest estaríamos mucho mejor

[andresin87]

https://2021.stateofjs.com/en-US/libraries/testing/

[arnau-rius]

An internal Tech Evolution proposal has been opened following this initiative.