Tu informe de mutation testing está lleno de supervivientes, y al menos uno de ellos no tiene sentido para ti.

La herramienta dice que cambió un > por >= en la línea 47, o reemplazó un bloque condicional completo por true, o mutó un string literal que ni siquiera sabías que se estaba probando. Lees el diff tres veces. Sigues sin entender qué comportamiento rompió el mutante, o qué prueba lo atraparía. Así que lo saltas. El mutante sobrevive. Tu score se mantiene baja.

Esta es la razón más común por la que la adopción del mutation testing se estanca. No el runtime. No los equivalent mutants. El momento en que un ingeniero mira fijamente a un superviviente, no puede asignarlo a una prueba faltante y decide que el mutation testing es solo ruido.

No lo es. Solo necesitas un punto de partida diferente.

El problema: estás empezando con la mutación, no con el código

La mayoría de los desarrolladores abordan los surviving mutants al revés. Leen el mutation diff, intentan entender qué bug sintético se introdujo, y luego intentan imaginar una prueba que atrapara ese bug específico.

Eso funciona para los casos obvios. Falla para cualquier cosa sutil.

La mutación podría estar dentro de una helper function a tres llamadas de profundidad. Podría afectar un side effect que no sabías que existía. Podría estar en generated code o en un framework callback. El diff muestra qué cambió, pero no por qué las pruebas existentes no le importaron. Si empiezas decodificando la mutación, estás haciendo reverse engineering sobre código sintético. Eso es difícil incluso para ingenieros experimentados.

El mejor enfoque es ignorar la mutación por completo y tratar al superviviente como una señal sobre tu código, no sobre el bug sintético.

Un mutante superviviente es solo una línea que tus pruebas no verifican

Cada surviving mutant apunta a una línea de código que se ejecutó durante las pruebas, pero cuya salida o side effects nunca fueron asserted.

La mutación podría haber sido cualquier cosa. El hecho de que sobreviviera significa una cosa: si esa línea produjera el resultado equivocado, tus pruebas seguirían pasando. No necesitas entender la mutación específica para arreglar eso. Necesitas entender lo que esa línea se supone que debe hacer, y escribir una prueba que verifique si lo hizo.

Este reframing cambia el problema del reverse-engineering de diffs sintéticos al diseño normal de pruebas.

El método: trabaja hacia atrás desde la línea, no hacia adelante desde la mutación

Aquí tienes un proceso de cuatro pasos que funciona con cualquier surviving mutant, sin importar cuán confuso se vea el diff.

Paso 1: Encuentra la línea exacta que tocó la mutación

El informe HTML de tu mutation testing tool mostrará la línea mutada inline con tu código fuente. Abre ese archivo y encuentra la línea original, no el diff.

Por ejemplo, digamos que Stryker reporta un survivor en esta función:

// pricing.js
function calculateDiscount(price, customer) {
  if (customer.loyaltyYears > 5) {
    return price * 0.85;
  }
  if (customer.isStudent) {
    return price * 0.90;
  }
  return price;
}

module.exports = { calculateDiscount };

La mutación cambió > por >= en el primer condicional. Ese es el detalle que podría confundirte. Olvídalo por ahora. La línea es if (customer.loyaltyYears > 5).

Paso 2: Pregunta qué se supone que debe hacer esta línea

No pienses en la mutación. Piensa en la business rule.

Esta línea se supone que debe verificar si un cliente ha sido leal por más de cinco años. Si es cierto, obtienen un descuento del 15%. El boundary importa. Un cliente con exactamente cinco años no debería obtener este descuento. Uno con seis años sí debería.

Ahora mira las pruebas existentes:

// pricing.test.js
const { calculateDiscount } = require('./pricing');

test('returns full price for new customers', () => {
  expect(calculateDiscount(100, { loyaltyYears: 0 })).toBe(100);
});

test('gives loyalty discount to long-term customers', () => {
  expect(calculateDiscount(100, { loyaltyYears: 6 })).toBe(85);
});

test('gives student discount to students', () => {
  expect(calculateDiscount(100, { isStudent: true })).toBe(90);
});

Las pruebas cubren ambas branches del primer if. Pero no prueban el boundary. loyaltyYears: 5 nunca aparece. Por eso el mutant >= sobrevivió. La herramienta encontró un gap que no sabías que estaba ahí.

Paso 3: Escribe una prueba que fallaría si esta línea estuviera equivocada

No necesitas escribir una prueba que mate esta mutación específica. Necesitas escribir una prueba que fallaría si la business rule fuera violada.

// pricing.test.js
test('does not give loyalty discount at exactly 5 years', () => {
  expect(calculateDiscount(100, { loyaltyYears: 5 })).toBe(100);
});

test('gives loyalty discount at 6 years', () => {
  expect(calculateDiscount(100, { loyaltyYears: 6 })).toBe(85);
});

Ahora el boundary es explícito. Si alguien cambia > por >=, la primera prueba falla porque un cliente con exactamente cinco años recibiría incorrectamente un descuento. El mutant muere. Nunca tuviste que entender qué significaba >= en el synthetic diff.

Paso 4: Vuelve a ejecutar la mutation test y confirma

Ejecuta tu mutation tool solo en este archivo, o ejecuta la suite completa si eres paciente. El survivor debería haber desaparecido. Si no es así, tu prueba en realidad no está ejercitando la línea que crees que sí. Revisa los datos de coverage para asegurarte.

Cuando la línea en sí es confusa

A veces la línea mutada está dentro de un library wrapper, un framework hook, o generated code que no escribiste. En esos casos, el survivor te está diciendo algo diferente: tienes código en tu codebase que ningún humano entiende lo suficientemente bien como para probarlo.

Este no es un problema de mutation testing. Es un problema de code quality que el mutation testing reveló.

Tus opciones son las mismas que serían sin mutation testing: refactorizar el código hasta que tenga una testable surface, o aceptar que este código no está probado y marcarlo como tal. Algunas herramientas te permiten ignorar líneas o archivos específicos. Usa ese poder con moderación. Cada ignored mutant es un bug que podría llegar a producción.

El caso difícil: mutaciones que cambian side effects

Los boundary checks son fáciles. Los side effects son más difíciles.

Considera esta función:

// logger.js
function logError(error, context) {
  const timestamp = new Date().toISOString();
  console.error(`[${timestamp}] ${context}: ${error.message}`);
  metrics.increment('error.count');
}

module.exports = { logError };

Una herramienta de mutation testing podría reemplazar la llamada completa a console.error por nada, o reemplazar el string template por un string vacío. Esos mutantes sobreviven si tus pruebas no verifican el log output.

La mayoría de los equipos no prueban logging. Eso suele estar bien. Pero si tus logs son consumidos por un alerting system, o si metrics.increment alimenta un dashboard que pagina al on-call, entonces saltarse estas pruebas es arriesgado.

El enfoque es el mismo. No estudies la mutación. Pregunta qué comportamiento se supone que debe producir esta línea. Si la respuesta es “a structured log entry with a timestamp”, escribe una prueba que haga assert sobre el log output:

// logger.test.js
const { logError } = require('./logger');

test('logs error with timestamp and context', () => {
  const spy = jest.spyOn(console, 'error').mockImplementation(() => {});
  logError(new Error('db timeout'), 'payment-service');
  expect(spy).toHaveBeenCalledWith(
    expect.stringMatching(/\d{4}-\d{2}-\d{2}T.*payment-service.*db timeout/)
  );
  spy.mockRestore();
});

El mutant que elimina la llamada a console.error ahora falla porque el spy no detecta ninguna llamada. El mutant que corrompe el string template falla porque el regex no coincide. No necesitabas entender ninguna de las mutaciones.

Por qué este enfoque escala mejor que estudiar mutaciones

Hay un número infinito de mutaciones posibles. Hay una cantidad finita de comportamientos que tu código se supone que debe tener.

Si intentas escribir pruebas que maten mutaciones específicas, estás jugando al whack-a-mole con bugs sintéticos. Si escribes pruebas que verifican el comportamiento real de tu código, las mutaciones mueren como side effect. El segundo enfoque es sostenible. El primero no lo es.

Así es también como evitas escribir pruebas que estén demasiado tightly coupled a la mutation tool. Una prueba que verifica que se usa > en la línea 47 es brittle. Una prueba que verifica que un cliente de cinco años paga full price es correcta.

La limitación: los equivalent mutants siguen existiendo

Este método no ayudará con los equivalent mutants, porque los equivalent mutants no representan pruebas faltantes. Representan transformaciones que producen un comportamiento idéntico.

Si una mutación cambia a + b por b + a en una operación conmutativa, ninguna prueba puede matarlo. No hay comportamiento faltante que verificar. Estos son falsos positivos, y toda herramienta de mutation testing los tiene. Aprende a reconocerlos, ignóralos y sigue adelante. No dejes que un noise floor del 2% de equivalent mutants te convenza de que el otro 98% también es ruido.

Empieza con los tres peores archivos

Si tu mutation score es baja y tienes docenas de supervivientes, no intentes entenderlos a todos. Elige los tres archivos con más supervivientes. Para cada archivo, elige las tres líneas más sospechosas. Aplica este método a cada una.

En menos de una hora, habrás escrito nueve pruebas que hacen tu codebase más correcta. Vuelve a ejecutar el mutation testing. Tu score saltará. Más importante aún, entenderás tu propio código mejor que antes.

Los mutantes no te están pidiendo que los entiendas. Te están pidiendo que entiendas tu código.

Preguntas frecuentes

¿Necesito entender el mutation operator para escribir la prueba? No. El mutation operator es una distracción. Enfócate en lo que la línea original se supone que debe hacer. Escribe una prueba para ese comportamiento. El mutant morirá como side effect.

¿Qué pasa si la línea mutada está dentro de una private function que no puedo probar directamente? Esa es una señal de diseño. Si una función tiene un comportamiento que vale la pena probar, debería ser testeable. O bien expónela para probarla, o pruébala a través de la public API que la llama. Si la prueba de la public API no puede alcanzar el comportamiento, el comportamiento podría ser dead code.

¿Debería matar a cada surviving mutant? No. Algunos mutantes tocan logging, metrics u otro observability code donde el costo de probar excede el valor. Establece un threshold que tenga sentido para tu codebase, y enfoca tu energía en los mutantes en la business logic.

¿Qué pasa si mi prueba mata al mutant pero aún se siente mal? Confía en esa sensación. Una prueba que casualmente mata a un mutant pero no verifica claramente una business rule es technical debt. Reescríbela para expresar el comportamiento esperado en domain language, no en test-language.