Inicialmente, las actualizaciones del DOM se realizaban manualmente, lo que resultaba en un código complejo y propenso a errores. Con la llegada de AJAX en los 2000, fue posible realizar solicitudes asincrónicas sin recargar la página, mejorando la interactividad. Más tarde, las Promises facilitaron el manejo de operaciones asincrónicas, simplificando el control de flujo en casos complejos. También, el uso de objetos Proxy ha permitido crear mecanismos reactivos que detectan y responden a cambios en los objetos, brindando una manera eficiente de gestionar el estado de la aplicación.

## Reactividad en Angular
Actualmente, nos encontramos en la era de los frameworks. Éstos han buscado formas de facilitar el trabajo de los desarrolladores en lo que respecta a la reactividad. Angular aportó nuevos enfoques:

- __Enlace de datos bidireccional:__ Esto comenzó con AngularJS y permitía que los cambios en el modelo de datos se reflejaran en el DOM (una dirección) y que los eventos del DOM provocaran acciones en el modelo de datos (la otra dirección). Lo primero fue posible gracias a la detección de cambios y a Zone.JS, que Angular introdujo como un sistema optimizado para detectar cambios en nuestros modelos de datos, utilizando Zone.JS para interceptar y rastrear todo tipo de tareas asíncronas (eventos, promesas, llamadas HTTP, etc.).
- __RxJS:__ Angular adoptó esta librería y la integró completamente en el framework; éste no se puede entender sin RxJS. Gracias a los Observables y sus diferentes operadores, los desarrolladores tienen una forma robusta y eficiente de trabajar con datos asíncronos y complejos, logrando un código mucho más predecible y reactivo.

Sin embargo, estos enfoques presentan algunos problemas. La detección de cambios puede generar problemas de rendimiento en aplicaciones grandes, por lo que Angular siempre ha tenido la fama de ser un framework lento. Aunque contaba con la detección de cambios OnPush, que restringía las condiciones para iniciar un ciclo de detección y no actualizaba todos los componentes a la vez si no era necesario, todos sabemos que la mayoría de los proyectos ignoran esta posibilidad y utilizan la detección de cambios por defecto.

Con RxJS sucede algo similar; aunque en los últimos años se ha notado que cada vez más personas utilizan Observables y Subjects en su código, muchas veces sigue siendo de forma no deseada. Se realizan muchas suscripciones manuales con posibles fugas de memoria y se ve un uso nulo de operadores más allá de filter, map y switchMap. No podemos olvidar a aquellos que ignoran por completo RxJS y lo utilizan únicamente cuando el framework lo exige. La razón es obvia: RxJS tiene una curva de aprendizaje difícil de gestionar para muchos desarrolladores, especialmente en un mundo de consultoría frenético, con fechas de entrega siempre próximas.

## Introducción de Signals
Las primeras discusiones sobre Signals en Angular aparecieron en 2022 con el RFC del equipo en GitHub. Estas se introdujeron por primera vez en Angular 16 de manera experimental. Aunque esta nueva forma de enfocar la reactividad no es realmente algo nuevo, sino que es muy parecida a las runas de Svelte, lanzadas en 2016, o a la reactividad en Vue.JS.
Una Signal es una variable cuyo valor puede cambiar en el tiempo y su cambio provoca la actualización de otras Signals dependientes. Los beneficios son claros:
- __Simplicidad__: No necesitamos lidiar con suscripciones ni operadores de RxJS, y tampoco con la asincronía.
- __Eficiencia__: Las Signals no requieren detección de cambios y pueden actualizar valores de forma más granular.
- __Depuración__: La depuración de observables siempre ha sido un dolor de cabeza, ya que conocer el valor actual es complicado si no se sigue el flujo desde el comienzo. Esto no sucede con las Signals porque estas siempre tienen un valor definido fácil de inspeccionar.

Si quieres conocer más sobre las Signals, te recomiendo consultar [la documentación oficial](https://angular.dev/guide/signals)

## Gestión del estado con Signals
Aunque solemos pensar en la gestión del estado global de nuestras aplicaciones, el estado de un único componente o servicio también debe gestionarse; a esto lo llamaremos gestión de estado localizado.

### Gestión de estado localizado
Gracias a las Signals, en los componentes ya no necesitaremos implementar OnChanges ni convertir nuestros @Input en setters para detectar cambios. Tampoco será necesario utilizar observables tan a menudo (por desgracia, las Signals aún no están integradas en módulos de Angular como el redireccionamiento o los formularios reactivos). En caso de necesitarlo, gracias a @angular/core/rxjs-interop, podremos convertir Observables a Signals fácilmente. En cuanto a servicios, lo mismo ocurre; nuestras propiedades no reactivas y Subjects pueden ser convertidos a Signals sin dificultad. 

Sin embargo, no debemos emocionarnos convirtiendo todo a Signals; los operadores de RxJS pueden ser muy útiles para ciertos casos de uso, y las llamadas externas a través de HttpClient no siempre pueden ser convertidas. La idea es que tanto Signals como RxJS convivan en un mismo proyecto, siendo utilizados cada uno según sus características: RxJS para flujos asíncronos y complejos que se benefician del uso de operadores, y Signals para propiedades reactivas síncronas con lógica accesible sin operadores; mientras que utilizamos el paquete de interoperabilidad para la conversión entre ambos tipos de datos.

### Gestión del estado global
Las librerías de gestión de estado global más utilizadas en Angular son NGRX y NGXS. Ambas intentan implementar el patrón FLUX con sus respectivas aproximaciones.

__NGXS Store__

Esta librería nos ofrece el paquete @ngxs/store y tras la salida de Signals, han sido rápidos para adaptar su solución a este nuevo paradigma. Se ha incluido un nuevo método “selectSignal” para que los selectores del estado sean de tipo Signal en lugar de Observables.

__NGRX__

En este caso, la librería nos ofrece varios paquetes para dos tipos de gestión. La gestión de estado por patrón FLUX con @ngrx/store y @ngrx/effects, y otra gestión más reducida y simple para sustituir los servicios con Subjects, que sería @ngrx/component-store. En ambos casos se ha incluido un nuevo método para que los selectores devuelvan una Signal en lugar de Observables, llamado “selectSignal”. 

Además de estas adaptaciones, el equipo de NGRX ha creado un nuevo paquete, @ngrx/signals, donde el estado es un Signal en sí y no hay dependencia alguna con RxJS. Y al igual que antes, en este caso contamos con la SignalStore para estados complejos y SignalState para aquellas gestión más simple y ligera.

## Conclusión
Está claro que las Signals son uno de los cambios más significativos en Angular de los últimos años. Este nuevo enfoque de reactividad afecta tanto al framework como a las librerías que utilizamos con él. Poco a poco, todos los módulos de Angular irán incorporando el uso de Signals, al igual que las librerías más populares. Esto apunta a un futuro sin Zone.JS ni detección de cambios, aportando ventajas como la mejora del rendimiento, la reducción de la carga inicial al eliminar las dependencias de Zone.JS y posiblemente de RxJS, así como la simplificación del proceso de depuración en caso de errores.

¿Y tú? ¿Has probado ya las Signals?


Gestión del estado con Signals en Angular

Esta herramienta se puede integrar directamente con IDEs como Visual Studio Code, lo que permite a los desarrolladores recibir sugerencias mientras escriben, acelerando el proceso de desarrollo y ayudando a superar bloqueos o dificultades durante el mismo. 

## ¿Cómo funciona realmente GitHub Copilot?

GitHub Copilot se puede utilizar en varios entornos, como editores de código, línea de comandos o  a través de un chat. En todos los casos, esta herramienta implementa un flujo de procesamiento diseñado para generar las sugerencias más precisas y cumplir sus términos de uso. 

El primer paso de este procesamiento consiste en recoger el contexto relevante del entorno del usuario, que puede variar según la forma de usar GitHub Copilot. Por ejemplo, cuando se utiliza integrado en un editor de código, el contexto puede incluir el contenido del archivo que se está editando, otros archivos relacionados del proyecto, otras pestañas del editor, así como el nombre y el tipo del archivo. Cuando se utiliza a través del chat, el contexto también incluye el historial de la conversación. Además, es posible restringir qué código puede utilizar como contexto y cuál no, a través de la configuración de la herramienta.

A continuación, se construye el *prompt*, que es la forma de indicarle al modelo qué datos debe procesar y en qué orden. Una serie de algoritmos extraen y priorizan la información recogida en el contexto para obtener las mejores respuestas posibles.

El *prompt* se envía de forma segura a un servicio proxy que realiza diferentes verificaciones, por ejemplo,  asegurándose de que el *prompt* no contenga lenguaje inapropiado o de que no represente un riesgo de hackeo de la herramienta.

En este momento, los LLMs (Large Language Models) entran en juego. Una vez que el *prompt* ha pasado todas las comprobaciones necesarias, se transfiere a los LLMs, que son un conjunto de modelos de IA entrenados tanto con lenguaje natural como con código fuente. GitHub, como plataforma líder en almacenamiento de código utilizada por desarrolladores de todo el mundo, aloja una gran cantidad de repositorios de código abierto. Parte de estos repositorios se han utilizado para entrenar estos modelos.

La respuesta generada por el modelo es nuevamente procesada por un servicio proxy que verifica que no incluya errores de vulnerabilidad como SQL Injection, bugs evidentes o identificadores únicos. Finalmente, esta respuesta es la sugerencia que se envía al usuario.

## Superando las barreras: datos, propiedad intelectual y licencias

¿El código generado se puede considerar original? ¿El código se copia de otro repositorio? ¿Mi código se utiliza para entrenar el modelo? Es habitual que surjan preocupaciones de este tipo relacionadas con el uso de esta herramienta. 

En primer lugar, hay que señalar que el código generado por Copilot es de uso libre para el desarrollador. GitHub ha indicado que los desarrolladores tienen el mismo derecho a usar el código generado por Copilot que el código escrito manualmente. Aún así, es fundamental que se revisen y ajusten las sugerencias según las necesidades específicas del proyecto y las políticas internas de cada organización, para asegurar que el código final cumple con los estándares y requisitos del proyecto.

El código generado por GitHub Copilot es producido por el modelo y no copiado directamente de repositorios públicos. Sin embargo, puede haber coincidencias con el código de estos repositorios. Para evitarlo, los administradores pueden habilitar un filtro que bloquea todas las sugerencias de código que coincidan aproximadamente en 150 caracteres con el código público de GitHub. Según las pruebas, alrededor del 1% del código sugerido puede coincidir con el de otros repositorios públicos, y esto ocurre con mayor frecuencia cuando el asistente de código tiene un contexto muy limitado.

Una consulta frecuente entre los usuarios es si GitHub Copilot utiliza los datos de su código para entrenar su modelo. De acuerdo con los términos de uso específicos de GitHub Copilot, por norma general, no se almacena ningún *prompt* para entrenar los LLMs base del asistente. Esto significa que ni el código ni el contexto recopilado en el entorno del usuario se guardan. Tras generar las sugerencias, los *prompts* son descartados. Sin embargo, dependiendo de la licencia de cada desarrollador y de las configuraciones establecidas en GitHub Copilot, pueden existir excepciones, por lo que es necesario revisar cada caso concreto.

Finalmente, es importante señalar que GitHub Copilot se utiliza bajo licencia. Existen licencias tanto para usuarios individuales como para empresas, estas últimas con términos adicionales de seguridad y cumplimiento. Esto permite a los desarrolladores y a las organizaciones seleccionar la opción que mejor se adapte a sus necesidades específicas.

## Y tú… ¿ya utilizas GitHub Copilot?

GitHub Copilot representa una evolución significativa en la manera de abordar el desarrollo de software, ofreciendo una combinación única de productividad, aprendizaje y calidad. Al adoptar esta herramienta, las organizaciones pueden acelerar sus ciclos de desarrollo, mejorar la calidad del código y fomentar un entorno de aprendizaje continuo para sus desarrolladores. 

Programando con Copilot

Una de las funcionalidades más utilizadas es GitHub Actions, que con el tiempo se ha vuelto crucial para gestionar y configurar la integración continua en nuestros proyectos, ofreciendo además muchas otras opciones.  

## Pero, ¿qué es GitHub Actions? 
GitHub Actions se centra en automatizar los flujos de trabajo o "workflows". Esto puede ir desde la simple creación y gestión de pequeñas tareas programadas, conocidas como "cron jobs", hasta la ejecución de software y el desarrollo completo de la integración y despliegue continuos (CI/CD) de nuestra aplicación. 

Para crear una GitHub Action, debemos definir archivos con extensión YAML que especifican las instrucciones o "jobs". A su vez, definimos conjuntos de pasos o "steps" que se ejecutan en un entorno totalmente limpio cada vez que se activan. Esto nos permite crear nuestra CI/CD, cuyo objetivo es agilizar y mejorar el ciclo de vida del software.

```typescript
name: CI/CD Ejemplo

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  build-and-test:
    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v3

    - name: Set up Node.js
      uses: actions/setup-node@v3
      with:
        node-version: '18'

    - name: Install dependencies
      run: npm ci

    - name: Run linter
      run: npm run lint

    - name: Run tests
      run: npm test

    - name: Build project
      run: npm run build

    - name: Upload artifact
      uses: actions/upload-artifact@v3
      with:
        name: dist
        path: dist

  deploy:
    needs: build-and-test
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/main' && github.event_name == 'push'

    steps:
    - name: Download artifact
      uses: actions/download-artifact@v3
      with:
        name: dist

    - name: Deploy to production
      run: |
        # Aquí irían los comandos para desplegar la aplicación
        # Por ejemplo, usando SSH para conectar a un servidor:
        # ssh user@example.com 'cd /path/to/app && git pull origin main && npm install && pm2 restart app'
```

Podemos elegir cuando ejecutar diferentes tareas: si al crear una “Pull Request”, al mergearla en una de las ramas principales, al hacer push.... hay multitud de opciones, pero la finalidad es siempre la misma: ejecutar y automatizar una seria de pasos para conseguir un fin, asegurando que el resultado tenga un mínimo de calidad y que cumpla su cometido. 

## Gestión de nuestra CI/CD 
Los workflows en GitHub Actions permiten automatizar diversas tareas críticas en el ciclo de desarrollo de software. Entre las actividades más útiles que podemos configurar se encuentran:

1. Comprobación de cobertura de tests: Podemos ejecutar automáticamente nuestras suites de pruebas y generar informes de cobertura. Esto nos ayuda a mantener un alto estándar de calidad y detectar rápidamente cualquier regresión.
2. Verificación de convenciones de código: Utilizando herramientas como ESLint, Prettier o similares, podemos asegurar que todo el código nuevo cumpla con las normas de estilo y mejores prácticas establecidas para el proyecto.
3. Análisis de accesibilidad: Podemos integrar herramientas que evalúen el cumplimiento de las pautas de accesibilidad web (WCAG), garantizando que nuestra aplicación sea inclusiva y utilizable por todos.
4. Análisis de seguridad: Implementar escaneos de seguridad para detectar vulnerabilidades en el código o en las dependencias utilizadas.
5. Optimización de rendimiento: Ejecutar pruebas de rendimiento y generar informes para identificar posibles cuellos de botella.
6. Generación de documentación: Automatizar la creación y actualización de documentación técnica basada en los cambios en el código.

Una buena implementación puede ahorrarnos muchos problemas en nuestras aplicaciones, desde simples errores en la gestión de las builds hasta cuestiones más avanzadas como la revisión de código en un entorno externo que nos alerte sobre su calidad y mantenibilidad. 

GitHub también nos ofrece un marketplace donde podemos mejorar nuestras Actions con extensiones creadas por la comunidad. Así, por ejemplo, podemos encontrar extensiones para integrarse con sistemas como SonarCloud, desplegar en diversos proveedores de cloud como Azure, AWS o Google, etc, etc.... Todas estas herramientas se pueden integrar para gestionar la calidad, mantenibilidad y funcionalidad de nuestro código en las pull requests (PR) o merges. 

## ¿Y qué pasa con los despliegues? 
Desde hace años, disponemos de gran variedad de alternativas en cuanto a despliegues. Si nos centramos en “cloud”, la oferta de servicios como AWS, Azure, Google Cloud, Oracle Cloud o Digital Ocean por nombrar unos pocos, nos ofrecen despliegues globales, con bajos costes operativos, alta agilidad y escalabilidad sin precedentes. Por otro lado, también contamos con despliegues en servidores "on-premise", donde los servidores están físicamente localizados en las instalaciones del cliente. Esta opción es común para software sensible, perteneciente a gobiernos, corporaciones no gubernamentales o entidades bancarias. 

En ambos casos, GitHub Actions es una herramienta versátil que nos permite adaptarnos fácilmente sin complicaciones adicionales, proporcionando autonomía al desarrollador y cumpliendo con los requisitos necesarios. 

## Ventajas frente a otras soluciones 
Jenkins es uno de los principales competidores ya que se trata de una solución Open Source que lleva en el mercado muchos años y ha sido adoptado tradicionalmente por muchas organizaciones para desempeñar estas tareas. Sin embargo, cada vez más, vemos clientes y colaboradores que migran su actual infraestructura a Github Actions, destacando principalmente su gestión y configuración de  workflows creados mediante archivos YAML, permitiendo hacer cambios “en caliente”. En cambio, Jenkins requiere una instalación y configuración avanzada desde el inicio, lo cual puede dificultar el desarrollo tanto de un producto mínimo viable (MVP) como de un software con un ciclo de vida largo. 

Otra gran ventaja de GitHub Actions es su amplia comunidad en el marketplace de plugins. Aunque Jenkins también tiene un marketplace similar, su entorno suele estar desactualizado o incluso abandonado, lo que puede llevar a situaciones donde un plugin esencial esté deprecado, presentando posibles problemas de seguridad y funcionamiento si actualizamos cualquier versión. 

En conclusión, establecer y mantener buenos pipelines de CI/CD es esencial. Una de las plataformas que más empleamos para ello es GitHub, el cual, más allá de su trabajo como repositorio de código nos permite implementar workflows que extienden su uso a todo el ciclo de vida de nuestro software. Esto nos permitirá mejorar la calidad, mantenibilidad, seguridad y robustez de nuestra aplicación en cada una de sus fases, automatizando los procesos manuales de pruebas y despliegues, lo que se traduce en grandes mejoras de productividad para los equipos de desarrollo.


CI/CD con GH Actions

En la actualidad, el desarrollo de aplicaciones web ha evolucionado hacia arquitecturas más modulares y escalables. Una de las técnicas más innovadoras del presente, plantea dividir  la aplicación web en pequeñas aplicaciones independientes, cada una con su propio front-end. Esta técnica, llamada microfrontends, no solo permite una mayor flexibilidad en el desarrollo y despliegue, sino que también facilita la colaboración entre equipos al permitir que cada uno trabaje de manera autónoma en su parte específica de la aplicación. Así, los microfrontends se presentan como una solución ideal para proyectos complejos y de gran escala.

__Webpack Module Federation__ es una herramienta clave para implementar esta arquitectura de manera eficiente, permitiendo a los desarrolladores compartir y cargar módulos en tiempo de ejecución. Introducida con Webpack 5, esta funcionalidad ha revolucionado la manera en que los equipos gestionan dependencias y recursos compartidos entre aplicaciones, eliminando la necesidad de un empaquetado conjunto desde el principio. Con Module Federation, es posible construir aplicaciones más dinámicas y flexibles, donde los módulos pueden ser actualizados y distribuidos de forma independiente sin afectar al conjunto del sistema.
En el contexto de microfrontends, Webpack Module Federation permite que varias aplicaciones independientes colaboren como una sola. Esta capacidad transforma la forma en que construimos y desplegamos las aplicaciones web modernas.

## Ventajas de Usar Webpack Module Federation

Utilizar Webpack Module Federation en una arquitectura de microfrontends ofrece múltiples ventajas:

1.	Desarrollo Independiente: Equipos distintos pueden trabajar en diferentes partes de la aplicación sin interferir unos con otros, lo que acelera el desarrollo y reduce conflictos de integración.
2.	Despliegue Incremental:  Se pueden actualizar y desplegar partes específicas de la aplicación sin necesidad de volver a desplegar todo el sistema, mejorando la agilidad y reduciendo el riesgo de errores.
3.	Escalabilidad: Es más sencillo escalar aplicaciones grandes ya que cada microfrontend puede gestionarse de manera independiente, optimizando recursos y rendimiento.
4.	Reutilización de Código:  Los módulos compartidos permiten reutilizar componentes y librerías comunes, reduciendo la duplicación de código y el tamaño del final de paquete desplegado.

## ¿Cuándo Usar Microfrontends con Webpack Module Federation?

Los microfrontends son ideales para proyectos que buscan escalabilidad y modularidad. Son especialmente útiles en las siguientes situaciones:

- Grandes Equipos de Desarrollo: Cuando múltiples equipos trabajan en una misma aplicación, los microfrontends facilitan la colaboración y el manejo de dependencias.
- Aplicaciones de Gran Escala: Para proyectos que se espera que crezcan significativamente en el tiempo, la modularidad de los microfrontends permite manejar esta expansión de manera ordenada y eficiente.
- Evolución Continua: Si una aplicación necesita actualizarse y desplegarse frecuentemente, los microfrontends permiten hacerlo de manera ágil y segura.

Para proyectos pequeños, los beneficios pueden no justificar la complejidad adicional. En estos casos, una arquitectura más tradicional podría ser más adecuada.

En conclusión, adoptar microfrontends con Webpack Module Federation puede transformar la manera en que desarrollas y escalas tus aplicaciones web. Esta arquitectura ofrece un alto grado de modularidad, permitiendo desarrollos independientes, despliegues incrementales y una mejor reutilización del código. Aunque implica una curva de aprendizaje y una mayor complejidad inicial, los beneficios a largo plazo tus grandes proyectos superan con creces estos desafíos y en Innusual contamos un con equipo de desarrolladores expertos que pueden ayudarte a potenciar tu aplicación de la mejor manera. 

En definitiva, los microfrontends representan el presente y con mucha certeza, el futuro del desarrollo web modular y escalable.


Microfrontends con Webpack Module Federation

Mejorando el rendimiento con cabeceras HTTP

Supongamos que tenemos un proyecto con una buena batería de tests unitarios, que nos ha asegurado una [cobertura de código](https://www.atlassian.com/es/continuous-delivery/software-testing/code-coverage) muy alta. Estamos satisfechos con ese dato, y pensamos que podremos pasar la noche tranquilos, sin tener pesadillas con bugs inesperados. Pero antes de cerrar los ojos para dormir, una duda nos asalta:

## ¿Quién testea los tests?

O en otras palabras: ¿cuánto confiamos en los tests unitarios de nuestro código? ¿es la cobertura un dato fiable?

Mi respuesta a la última pregunta es... no necesariamente. Veámoslo en un par de ejemplos:

1. Nuestro test puede cubrir "falsos positivos" 🥸:

    dada esta función que retorna si el agua está congelada según una temperatura dada:

   ```typescript
   const isFrozenWater = (waterTemperature: number) => waterTemperature <= 0;
   ```

   podemos obtener un 100% de cobertura de la función únicamente añadiendo este test:

   ```typescript
   test("should return true when the temperature of the water is -15ºC", () => {
     const isIce = isFrozenWater(-15);
     expect(isIce).toBe(true);
   });
   ```

   pero, ¿qué pasaría si la función `isFrozenWater` se modificara por error?

   ```typescript
   const isFrozenWater = (waterTemperature: number) => waterTemperature < 0;
   ```

   Nuestro test seguiría siendo válido, y la función estaría cubierta al 100%, pero la funcionalidad no es correcta.

2. Nuestro test puede no estar probando nada 🤥:

   ¿quién no se ha encontrado alguna vez un repositorio con tests sin ningún expect asociado, añadidos únicamente con objeto de recorrer el código y cumplir con la cobertura mínima que establece el CI/CD?
   Dada la misma función `isFrozenWater` del punto anterior, podríamos conseguir un 100% de cobertura con este test:

   ```typescript
   test("should return true when the temperature of the water is -15ºC", () => {
     const isIce = isFrozenWater(-15);
     //usamos un fake expect que nunca fallará, y que es agnóstico a lo que se pretende testear 😵
     expect(true).toBe(truthy);
   });
   ```

   o, incluso, con éste:

   ```typescript
   test("should return true when the temperature of the water is -15ºC", () => {
     const isIce = isFrozenWater(-15);
     //sólo se ejecuta la función, no se testea nada 😱
   });
   ```

## Incorporando el concepto de "mutantes"

Las pruebas de mutación consisten en introducir pequeñas alteraciones (o **_mutantes_**) en el código que se va a testear para, a continuación, ejecutar las pruebas unitarias con el código modificado. Cada mutante debería hacer que algún test falle; en ese caso, se ha eliminado (_mutant is killed_), de lo contrario, ha sobrevivido (_mutant survived_).

De esta forma, estamos generando una nueva medida de calidad, mucho más fiable que la cobertura, llamada "% de mutantes eliminados" (_% of mutants killed_ o _mutation score_). Nuestro código será más seguro cuanto más cercano esté este índice al 100%.

Estos son los mutantes más comunes que podemos encontrar en este tipo de pruebas:

| Original | Mutante |
| ---------------------------- | :------------------------------ |
| `a + b` | `a - b` |
| `a / b` | `a * b` |
| `a < b` | `a > b` |
| `a === b` | `a !== b` |
| `a && b` | `a &#124;&#124; b` |
| `a ?? b` | `a && b` |
| `const company = "innusual"` | `const company = ""` |
| `const list = [1, 2, 3, 4]` | `const list = []` |
| `if (a > b) { ... }` | `if (true) { ... }` |
| `function fn() { ...}` | `function fn() { /* EMPTY */ }` |

Para añadir pruebas de mutaciones en Javascript, la librería más popular es Stryker Mutator.

## Stryker

Además del súper enemigo de los X-Men, Stryker es una herramienta de código abierto diseñada originalmente para Javascript (aunque ya han incorporado versiones para C# y Scala)... y a ambos les encanta matar mutantes.

Es fácil de instalar y configurar, con una documentación minuciosa y amena, y nos ofrece una interfaz visual muy intuitiva de los mutantes que crea y el resultado de aplicar nuestros test sobre ellos.

Empezar a usar Stryker en nuestro proyecto es muy sencillo.

El primer paso es instalar el paquete de npm que nos descargará el `cli` de Stryker:

```
 $ npm install -g stryker-cli
```

Después instalaremos Stryker en el proyecto ejecutando:

```
 $ npm init stryker
```

Este comando nos hará una serie de preguntas sobre el proyecto para configurar Stryker según esos parámetros.
A esta configuración inicial, le añadiremos las modificaciones que consideremos necesarias (archivos a analizar o ignorar, formato de los reportes, deshabilitar cierto tipo de mutantes, etc).

Ya podemos ejecutar Stryker:

```
 $ npx stryker run
```

En nuestro ejemplo anterior, obtendríamos el siguiente resultado:

![initial report](//images.ctfassets.net/jjnvunjhj2gv/4Ddpwx0etEagvM75ehLB3z/9da601d6f4cbabc90015972f50d0acf5/01_report_60.png)

Se han creado 5 mutantes para el método `isFrozenWater`, y nuestro test ha podido eliminar 3 de ellos.

- 💀 se han eliminado:

    ![mutant killed 01](//images.ctfassets.net/jjnvunjhj2gv/4xPIv4pDue50wn0SpvE1un/1d95dccf8e2e1166a7250b9c5288398b/02-01_mutant_killed.png)

    ![mutant killed 02](//images.ctfassets.net/jjnvunjhj2gv/3hR9zUEpvSLIPoRfELpprb/e9955a346fe16db8a64cdcf4d9339341/02-02_mutant_killed.png)

    ![mutant killed 03](//images.ctfassets.net/jjnvunjhj2gv/4bsVjGiri5IXPWLLUl9yDt/4ae25684ac216b47d607c96e8d03fd03/02-03_mutant_killed.png)

- 👽 han sobrevivido:
  ![mutant survived 01](//images.ctfassets.net/jjnvunjhj2gv/7kVdYR6c7KHND5GR4nVEbM/c3b333017df753858d965ffd45adcadf/03-01_mutant_survived.png)

  Para eliminar este mutante, vamos a añadir un test con un valor "de borde", que compruebe qué ocurre cuando la temperatura es 0ºC:

  ```typescript
  test("should return true when the temperature of the water is 0ºC", () => {
    const isIce = isFrozenWater(0);
    expect(isIce).toBe(true);
  });
  ```

  ![mutant survived 02](//images.ctfassets.net/jjnvunjhj2gv/3w0HS7kxVWd7XM9XeqmUwl/1d13bd098b06332b009f2f446e6730b9/03-02_mutant_survived.png)

  Para eliminar este mutante, vamos a añadir un test que compruebe qué ocurre cuando la temperatura es mayor a 0ºC:

  ```typescript
  test("should return false when the temperature of the water is 15ºC", () => {
    const isIce = isFrozenWater(15);
    expect(isIce).toBe(false);
  });
  ```

  Tras añadir los dos nuevos test, si volvemos a ejecutar Stryker, veremos que el "mutation score" ha subido al 100%:

![final report](//images.ctfassets.net/jjnvunjhj2gv/5TQV28WxQNZMnzuXYFs53d/9a786a21f0d558ac1b9bfe26dba0c514/04_report_100.png)

Igual que al inicio, tenemos cobertura del 100% del código, pero ahora nuestras pruebas unitarias son mucho más robustas.

## Consideraciones a tener en cuenta

Cuando añadimos una herramienta como Stryker a nuestros proyectos, es de vital importancia afinar al máximo posible la configuración, ya que el principal problema de este tipo de pruebas es el tiempo de ejecución que requieren (pensemos que va a ejecutar los test por cada mutante que se genere):

- Debemos restringir la ejecución de las pruebas únicamente a los archivos que están siendo testeados (y excluir los archivos de test unitarios, ya que éstos no los queremos mutar), para no generar mutantes innecesarios.
- Debemos configurar el tipo de mutaciones que queremos que se aplique al código, ya que de lo contrario, se aplicarán todas por defecto y la mayoría de las veces no todas son necesarias.

Además de la propia configuración de Stryker, debemos tener en cuenta que, debido a los tiempos tan largos de ejecución de los tests de mutación, hay que valorar si es conveniente añadirlos a las pipelines de CI/CD (es compatible la [integración con SonarQube](https://stryker-mutator.io/docs/mutation-testing-elements/sonarqube-integration/)), o quizá sea mejor opción programar una ejecución periódica, o puntual en ciertas partes sensibles del código.

## Conclusiones

Como hemos visto, las pruebas de mutación son útiles para medir la calidad de nuestros test unitarios, comprobar que son efectivos y que se han añadido con el único objetivo de aumentar la cobertura de nuestro proyecto. Stryker es una herramienta muy potente y de uso sencillo para implementar estas pruebas en Javascript, y nos ayuda a encontrar tests que se nos han olvidado y asegurar más nuestro código en las zonas más críticas.

Más que intentar alcanzar un 100% de Mutation Score, debemos decidir sobre qué parte del código aplicarlo, cuándo hacerlo, y saber interpretar los resultados que nos aporta, para actuar de la mejor forma posible para mejorarlos: bien añadir tests, bien modificar el código para eliminar las mutaciones sin perder legibilidad.

## Bonus Track

- Documentación oficial de [Stryker Mutator](https://stryker-mutator.io/)
- charla ["Who's testing the tests?"](https://fosdem.org/2024/schedule/event/fosdem-2024-1683-who-s-testing-the-tests-mutation-testing-with-strykerjs/), de Nico Jansen en la FOSDEM'24
