Unit Test vs Integration Test
Das Fundament der iOS-Teststrategie: Unit-Tests, die eine Einheit isolieren, oder Integrationstests, die das Zusammenspiel von Komponenten prüfen? Wie baut man die Testpyramide richtig auf?
Nativer ESM/TS-Test-Runner mit der Geschwindigkeit von Vite selbst
13 Jahre ausgereift und React Natives Standard
In einem neuen Vite- oder Nuxt-Projekt sollte Vitest der Standard sein: Du teilst dieselbe `vite.config.js`. Bei Next.js bleibt die Konfiguration getrennt (der Compiler ist nicht Vite), aber du bekommst natives ESM/TypeScript ohne ein zusätzliches Transform-Paket. Wenn du jedoch eine große, funktionierende Jest-Suite hast — besonders wenn sie von RN/Metro abhängt —, kann der Migrationsaufwand den Nutzen übersteigen. Wähle den dritten Weg: Schreibe neue Tests in Vitest und belasse die bestehende Suite in Jest — beide können im selben Monorepo koexistieren.
| Kategorie | Vitest 5 | Jest |
|---|---|---|
| Performance | 9/10 | 7/10 |
| Erlernbarkeit | 7/10 | 7/10 |
| Ökosystem | 6/10 | 9/10 |
| Community | 6/10 | 9/10 |
| Arbeitsmarkt | 6/10 | 8/10 |
| Zukunftssicherheit | 9/10 | 6/10 |
// Vitest 5 - Test fuer die Funktion, die die Warenkorbsumme berechnet
// vitest.config.ts teilt sich vite.config.ts; kein zusaetzlicher Transform noetig
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 ist standardmaessig true, kein zusaetzlicher Cleanup-Aufruf noetig
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 neue API: unterschiedliches Mock-Verhalten je nach Argument
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 (nur das 'web'-Projekt + Coverage-Report)// Jest 30 - Test fuer die Funktion, die die Warenkorbsumme berechnet
// babel.config.js oder eine ts-jest-Transform-Kette muss separat eingerichtet werden
const { calculateCartTotal } = require('./cart')
const { fetchDiscount } = require('./discount-api')
jest.mock('./discount-api')
describe('calculateCartTotal', () => {
afterEach(() => {
jest.clearAllMocks() // In Jest nicht der Standard, wird manuell aufgerufen
})
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')
})
})
// Nur das 'web'-Paket im Monorepo ausfuehren: jest --projects packages/web --coverageIn einem neuen Vite- oder Nuxt-Projekt sollte Vitest der Standard sein: Du teilst dieselbe `vite.config.js`. Bei Next.js bleibt die Konfiguration getrennt (der Compiler ist nicht Vite), aber du bekommst natives ESM/TypeScript ohne ein zusätzliches Transform-Paket. Wenn du jedoch eine große, funktionierende Jest-Suite hast — besonders wenn sie von RN/Metro abhängt —, kann der Migrationsaufwand den Nutzen übersteigen. Wähle den dritten Weg: Schreibe neue Tests in Vitest und belasse die bestehende Suite in Jest — beide können im selben Monorepo koexistieren.
Kostenlose Beratung erhaltenNein, nicht eins zu eins. Beide werden im September 2026 aktiv weiterentwickelt: Vitest 5.0 (3. September 2026) und Jest 30.5.2 (18. September 2026). In Vite- und Nuxt-basierten Projekten ist der Setup-Aufwand bei Vitest geringer, weil es die eigene Transform-Pipeline der Anwendung wiederverwendet; Jest bleibt vor allem bei React Native/Metro und bestehenden großen Codebasen relevant.