JavaScript
Explica cómo diseñar pruebas útiles en JavaScript, aislar dependencias y cubrir comportamiento con unitarias, integración y flujos completos.
Una prueba ejecuta un comportamiento bajo condiciones controladas y comprueba un resultado observable.
function calculateTotal(items) {
return items.reduce(
(total, item) => total + item.price,
0,
);
}expect(
calculateTotal([
{ price: 10 },
{ price: 20 },
]),
).toBe(30);Arrange → preparar
Act → ejecutar
Assert → comprobarconst cart = createCart();
cart.add(product);
expect(cart.total).toBe(product.price);Frágil:
expect(service.internalCache.size).toBe(1);Más estable:
expect(await service.find(product.id))
.toEqual(product);Prueba la API pública salvo que una unidad interna tenga responsabilidad propia.
Verifican una unidad pequeña con dependencias controladas.
Aportan para:
Comprueban colaboración real entre varias piezas:
Capturan errores de contratos que mocks aislados pueden ocultar.
Ejecutan flujos cercanos a la experiencia real.
abrir página
↓
llenar formulario
↓
enviar
↓
ver resultadoSon valiosos para caminos críticos, pero más lentos y sensibles al entorno.
No existe una proporción universal. Busca:
Para una cantidad:
-1
0
1
máximo
máximo + 1
NaN
Infinity
string
null
undefinedLas fronteras descubren más errores que repetir únicamente el camino feliz.
it.each([
[0, true],
[1, true],
[-1, false],
[NaN, false],
])("validates %s", (value, expected) => {
expect(isValidQuantity(value)).toBe(expected);
});expect(() => createPercentage(200))
.toThrow(RangeError);Para contratos propios:
expect(() => requireProduct([], "p1"))
.toThrow(ProductNotFoundError);También verifica propiedades estables, no textos completos si el mensaje puede cambiar.
await expect(loadProduct("p1"))
.resolves.toMatchObject({ id: "p1" });await expect(loadProduct("missing"))
.rejects.toBeInstanceOf(ProductNotFoundError);No olvides retornar o await la expectativa; una prueba puede terminar antes del rechazo.
Peligroso:
it("fails", () => {
load().then((value) => {
expect(value).toBe(10);
});
});La prueba exterior puede finalizar antes.
it("works", async () => {
const value = await load();
expect(value).toBe(10);
});vi.useFakeTimers();
const callback = vi.fn();
setTimeout(callback, 1000);
vi.advanceTimersByTime(1000);
expect(callback).toHaveBeenCalledOnce();Los fake timers cambian el entorno. Promesas, microtasks y APIs del navegador pueden necesitar pasos adicionales según la herramienta.
No uses timers falsos para esconder un diseño difícil de controlar.
const repository = {
save: vi.fn().mockResolvedValue(product),
};Un mock verifica interacción, pero puede duplicar una suposición incorrecta sobre la dependencia real.
Prefiere fakes pequeños y tests de contrato cuando la integración importa.
El nombre importa menos que entender qué realidad estás reemplazando.
const service = createOrderService({
repository: fakeRepository,
clock: fakeClock,
idGenerator: fakeIdGenerator,
});Hace deterministas tiempo, IDs y efectos sin mutar globals.
const clock = {
now: () => new Date("2026-07-23T14:00:00Z"),
};No dependas de la hora real en una prueba de reglas de negocio.
const random = () => 0.5;Inyecta o fija una seed para reproducibilidad.
Prueba desde el comportamiento del usuario:
button.click();
expect(status.textContent).toBe("Saved");element.click() no reproduce todos los detalles de una interacción real. Herramientas de user-event pueden modelar foco, teclado y secuencias con mayor fidelidad.
Intercepta solicitudes en una frontera cercana a HTTP para probar Request, Response, status y payload, no solo una función mockeada.
Un mock de fetch que siempre retorna un objeto incompleto puede ocultar errores como body consumido o headers.
Son útiles para estructuras grandes relativamente estables, pero pueden convertirse en aprobaciones masivas sin lectura.
Prefiere assertions específicas cuando el comportamiento importante cabe en pocas propiedades.
Genera muchos valores y verifica una propiedad.
Ejemplo conceptual:
para cualquier array de números finitos:
sort(result) conserva longitud y elementosAporta en parsers, serialización, algoritmos e invariantes.
Cuando corriges un bug:
Coverage muestra líneas, ramas y funciones ejecutadas. No demuestra assertions correctas ni calidad.
100% ejecutado ≠ 100% comportamiento correctoÚsala para encontrar huecos, no como objetivo aislado.
Causas comunes:
No soluciones una prueba flaky añadiendo sleeps arbitrarios. Encuentra la condición no controlada.
it("releases inventory when payment fails", async () => {
const inventory = {
reserve: vi.fn().mockResolvedValue({ id: "r1" }),
release: vi.fn().mockResolvedValue(undefined),
};
const payments = {
charge: vi.fn().mockRejectedValue(
new Error("Declined"),
),
};
await expect(
checkout(order, { inventory, payments }),
).rejects.toBeInstanceOf(CheckoutError);
expect(inventory.release)
.toHaveBeenCalledWith("r1");
});La prueba protege un efecto de compensación, no una línea interna.
¿Por qué una prueba con 100% de cobertura puede no detectar un cálculo incorrecto?
Porque coverage solo muestra que las líneas se ejecutaron. La prueba puede no contener una assertion que verifique el resultado correcto.
Linting, formatting y compatibilidad explica qué problemas pueden detectar las herramientas antes de ejecutar.