Cómo probar métodos privados en TypeScript

Cualquier desarrollador de software que escriba pruebas unitarias se enfrenta tarde o temprano a este dilema: escribes una clase compleja con un método auxiliar privado y quieres escribir una prueba unitaria directa para esa lógica en específico.

Cuando intentas llamar a service.handleError() en tu archivo de pruebas, el compilador de TypeScript te bloquea:

Property 'handleError' is private and only accessible within class 'ProductService'.

¿Es una mala práctica probar métodos privados? ¿Qué opciones tienes cuando necesitas probar lógica interna crítica?

En este artículo, te voy a mostrar cuatro formas de probar métodos privados en TypeScript, te explicaré la diferencia clave entre private de TypeScript y los campos #private de JavaScript, y revisaremos cuándo conviene refactorizar.

El ejemplo: un servicio con un manejador de errores privado

Imagina este servicio en Angular o Node.js que maneja peticiones HTTP y formatea errores internamente:

import { Injectable, inject } from '@angular/core';
import { HttpClient } from '@angular/common/http';
import { firstValueFrom } from 'rxjs';
 
@Injectable({ providedIn: 'root' })
export class ProductService {
  #http = inject(HttpClient);
 
  async getProducts(): Promise<string[]> {
    try {
      const response = await firstValueFrom(
        this.#http.get<{ data: string[] }>('/api/products')
      );
      return response.data;
    } catch (error) {
      const formatted = this.formatErrorMessage(error as Error);
      console.error(formatted);
      return [];
    }
  }
 
  private formatErrorMessage(error: Error): string {
    return `[ProductService Error]: ${error.message}`;
  }
}

El método formatErrorMessage está marcado como private. Veamos las cuatro estrategias para probarlo.

Estrategia 1: Notación de corchetes (el atajo pragmático)

La palabra clave private en TypeScript es solo una comprobación en tiempo de compilación. Una vez que tu código TypeScript se compila a JavaScript, la palabra clave private desaparece por completo.

En tiempo de ejecución, los métodos privados estándar de TypeScript son propiedades normales de JavaScript en el prototipo del objeto. Puedes evitar la verificación del compilador usando el acceso por índice con corchetes:

import { ProductService } from './product.service';
 
describe('ProductService', () => {
  it('should format error messages correctly', () => {
    const service = new ProductService();
    const testError = new Error('Database connection failed');
 
    // Evitamos la comprobación del compilador de TypeScript usando notación de corchetes
    const result = service['formatErrorMessage'](testError);
 
    expect(result).toBe('[ProductService Error]: Database connection failed');
  });
});

También puedes convertir la instancia a any:

const result = (service as any).formatErrorMessage(testError);

Cuándo usar esta opción:

Usa esta opción cuando estés trabajando con código legado y necesites cobertura de pruebas rápida sin refactorizar las clases en producción.

Advertencia: Esto solo funciona con la palabra clave private de TypeScript. ¡NO funcionará con los campos #private de JavaScript!

Diferencia clave: private de TypeScript frente a #private de JavaScript

Muchos desarrolladores confunden la palabra clave private de TypeScript con los campos privados nativos de JavaScript (#methodName).

export class ModernService {
  // Privado en tiempo de compilación de TypeScript
  private tsPrivate(): string {
    return 'Accessible via bracket notation';
  }
 
  // Campo privado en tiempo de ejecución de ECMAScript
  #jsPrivate(): string {
    return 'Enforced by the JS engine';
  }
}

Si tu clase usa #formatErrorMessage, la notación de corchetes va a fallar. Esto nos lleva a nuestras soluciones arquitectónicas más limpias.

Estrategia 2: Extraer a funciones auxiliares puras e independientes (Recomendada)

Cuando un método privado contiene lógica de negocio importante, cálculos o formateo de cadenas, por lo general no debería estar dentro de la clase misma.

Mueve esa lógica a una función pura independiente, ya sea en el mismo archivo o en un archivo de utilidades:

// product.utils.ts
export function formatErrorMessage(error: Error): string {
  return `[ProductService Error]: ${error.message}`;
}

Luego usa la función dentro de tu servicio:

import { formatErrorMessage } from './product.utils';
 
export class ProductService {
  private format(error: Error) {
    return formatErrorMessage(error);
  }
}

Ahora puedes probar formatErrorMessage directamente sin necesidad de crear instancias de la clase, simular dependencias ni hacer conversiones de tipos:

import { formatErrorMessage } from './product.utils';
 
describe('formatErrorMessage', () => {
  it('formats error with prefix', () => {
    const error = new Error('Network timeout');
    expect(formatErrorMessage(error)).toBe('[ProductService Error]: Network timeout');
  });
});

Este enfoque genera código mucho más fácil de probar, reutilizar y mantener.

Estrategia 3: Usar protected y una subclase de prueba

Si el método necesita acceder al estado protegido interno en la instancia de la clase, cambia el modificador de private a protected.

Luego, en tu archivo de pruebas, crea una subclase de prueba que exponga el método protegido de forma pública:

// En tu archivo de pruebas:
class TestableProductService extends ProductService {
  public exposeFormatErrorMessage(error: Error): string {
    return this.formatErrorMessage(error);
  }
}
 
describe('ProductService with Subclass Sandbox', () => {
  it('exposes protected method for verification', () => {
    const testService = new TestableProductService();
    const result = testService.exposeFormatErrorMessage(new Error('Auth failed'));
 
    expect(result).toBe('[ProductService Error]: Auth failed');
  });
});

Este patrón mantiene el método oculto para el código consumidor y, al mismo tiempo, le da a tu suite de pruebas un punto de entrada con tipos seguros.

Estrategia 4: Probar a través de métodos públicos (pruebas de comportamiento)

La filosofía más limpia al hacer pruebas es: prueba el comportamiento, no los detalles de implementación.

En lugar de probar formatErrorMessage directamente, prueba el método público getProducts() y verifica su resultado observable cuando ocurre un error:

it('returns empty array and logs error when request fails', async () => {
  const consoleSpy = jest.spyOn(console, 'error').mockImplementation();
  
  // Configuramos el mock para que falle
  mockHttp.get.mockReturnValue(throwError(() => new Error('Server 500')));
 
  const products = await service.getProducts();
 
  expect(products).toEqual([]);
  expect(consoleSpy).toHaveBeenCalledWith('[ProductService Error]: Server 500');
  
  consoleSpy.mockRestore();
});

Al probar el contrato público, tus pruebas no se romperán si más adelante decides refactorizar o cambiar de nombre los métodos privados internos.

Resumen comparativo

Mi recomendación:

• Para código existente: Usa la notación de corchetes o prueba el método público.
• Para código nuevo: Extrae la lógica compleja a funciones puras y pruébalas directamente.

Conclusiones y siguientes pasos

Probar métodos privados en TypeScript se reduce a elegir la herramienta adecuada para cada caso:

1. Recuerda la diferencia entre compilación y ejecución: private de TypeScript desaparece en tiempo de ejecución, pero #private queda protegido de forma permanente.
2. Prioriza el comportamiento público: Prueba lo que el usuario o consumidor ve, no la estructura interna.
3. Extrae lógica pura: Las funciones puras sin efectos secundarios en clases siempre son las más fáciles de probar.

Si este artículo te resultó útil, revisa estos artículos relacionados sobre TypeScript y pruebas unitarias:

• Why Avoid Using 'any' in TypeScript
• How and When to Use Mocks or Spies in Unit Testing
• Abstract Classes in TypeScript
• How to Check Types in TypeScript