Unit Test vs Integration Test
La base de la estrategia de testing en iOS: ¿tests unitarios que aíslan la unidad o tests de integración que validan la interacción entre componentes? ¿Cómo construir correctamente la pirámide de testing?
El test runner nativo de ESM/TS con la velocidad propia de Vite
Con 13 años, maduro y el valor por defecto de React Native
En un proyecto nuevo basado en Vite o Nuxt, la opción por defecto debería ser Vitest: compartes el mismo `vite.config.js`. En Next.js la configuración queda separada (su compilador no es Vite), pero obtienes soporte nativo de ESM/TypeScript sin instalar un paquete de transformación adicional. Pero si tienes una suite de Jest grande y en funcionamiento, especialmente si dependes de RN/Metro, el coste de la migración puede superar el beneficio. Elige la tercera vía: escribe las pruebas nuevas en Vitest y deja la suite existente en Jest — ambos pueden convivir en el mismo monorepo.
| Categoría | Vitest 5 | Jest |
|---|---|---|
| Rendimiento | 9/10 | 7/10 |
| Facilidad de aprendizaje | 7/10 | 7/10 |
| Ecosistema | 6/10 | 9/10 |
| Comunidad | 6/10 | 9/10 |
| Mercado laboral | 6/10 | 8/10 |
| A prueba de futuro | 9/10 | 6/10 |
// Vitest 5 - Prueba de la función que calcula el total del carrito
// vitest.config.ts comparte vite.config.ts; no requiere transformación adicional
import { describe, it, expect, vi } from 'vitest'
import { calculateCartTotal } from './cart'
import { fetchDiscount } from './discount-api'
vi.mock('./discount-api')
describe('calculateCartTotal', () => {
// Vitest 5: clearMocks es true por defecto, no requiere llamada de limpieza adicional
it('indirim kodu olmadan ara toplami dogru hesaplar', () => {
const items = [
{ price: 129.9, qty: 2 },
{ price: 49.5, qty: 1 },
]
expect(calculateCartTotal(items)).toBeCloseTo(309.3, 2)
})
it('gecerli indirim kodunda vi.when ile kosullu mock kullanir', async () => {
// Vitest 5 nueva API: comportamiento de mock distinto según el argumento
vi.when(fetchDiscount).calledWith('SEPET10').thenResolve({ percent: 10 })
vi.when(fetchDiscount).calledWith('GECERSIZ').thenReject(new Error('invalid code'))
const items = [{ price: 100, qty: 1 }]
const total = await calculateCartTotal(items, 'SEPET10')
expect(total).toBeCloseTo(90, 2)
expect(fetchDiscount).toHaveBeenCalledWith('SEPET10')
})
it('gecersiz kod hata firlatir', async () => {
vi.when(fetchDiscount).calledWith('GECERSIZ').thenReject(new Error('invalid code'))
const items = [{ price: 100, qty: 1 }]
await expect(calculateCartTotal(items, 'GECERSIZ')).rejects.toThrow('invalid code')
})
})
// Monorepo: vitest -p web --coverage (solo el proyecto 'web' + informe de cobertura)// Jest 30 - Prueba de la función que calcula el total del carrito
// babel.config.js o la cadena de transformación ts-jest debe estar configurada aparte
const { calculateCartTotal } = require('./cart')
const { fetchDiscount } = require('./discount-api')
jest.mock('./discount-api')
describe('calculateCartTotal', () => {
afterEach(() => {
jest.clearAllMocks() // en Jest no es el valor por defecto, se llama manualmente
})
it('indirim kodu olmadan ara toplami dogru hesaplar', () => {
const items = [
{ price: 129.9, qty: 2 },
{ price: 49.5, qty: 1 },
]
expect(calculateCartTotal(items)).toBeCloseTo(309.3, 2)
})
it('gecerli indirim kodunda mockResolvedValue kullanir', async () => {
fetchDiscount.mockImplementation((code) => {
if (code === 'SEPET10') return Promise.resolve({ percent: 10 })
return Promise.reject(new Error('invalid code'))
})
const items = [{ price: 100, qty: 1 }]
const total = await calculateCartTotal(items, 'SEPET10')
expect(total).toBeCloseTo(90, 2)
expect(fetchDiscount).toHaveBeenCalledWith('SEPET10')
})
it('gecersiz kod hata firlatir', async () => {
fetchDiscount.mockRejectedValue(new Error('invalid code'))
const items = [{ price: 100, qty: 1 }]
await expect(calculateCartTotal(items, 'GECERSIZ')).rejects.toThrow('invalid code')
})
})
// ejecuta solo el paquete 'web' en el monorepo con jest --projects packages/web --coverageEn un proyecto nuevo basado en Vite o Nuxt, la opción por defecto debería ser Vitest: compartes el mismo `vite.config.js`. En Next.js la configuración queda separada (su compilador no es Vite), pero obtienes soporte nativo de ESM/TypeScript sin instalar un paquete de transformación adicional. Pero si tienes una suite de Jest grande y en funcionamiento, especialmente si dependes de RN/Metro, el coste de la migración puede superar el beneficio. Elige la tercera vía: escribe las pruebas nuevas en Vitest y deja la suite existente en Jest — ambos pueden convivir en el mismo monorepo.
Solicita una consultoría gratuitaNo, no lo sustituye por completo. Ambos están en desarrollo activo en septiembre de 2026: Vitest 5.0 (3 de septiembre de 2026) y Jest 30.5.2 (18 de septiembre de 2026). En proyectos basados en Vite y Nuxt, Vitest tiene una carga de configuración menor porque reutiliza el propio pipeline de transformación de la aplicación; Jest sigue vigente sobre todo en React Native/Metro y en bases de código grandes ya existentes.