Dies ist eine alte Version des Dokuments!


LU16b - Testing

Testing stellt sicher, dass eine Web-Applikation so funktioniert, wie erwartet – bevor sie in Production gelangt. Es gibt vier Testarten, die sich in Umfang, Geschwindigkeit und Aufwand unterscheiden.

 Testing-Pyramide: Unit → API/Integration → UI/E2E → Manuell
Testing-Pyramide mit vier Ebenen

Die Pyramide zeigt die empfohlene Gewichtung:

  • Unten (breit): Viele schnelle Unit Tests – testen einzelne isolierte Funktionen.
  • Mitte: Weniger Integration Tests – testen das Zusammenspiel von Funktionen.
  • Oben (schmal): Wenige, langsame End-to-End Tests – aufwändig, aber realitätsnah.
  • Wolke: Manuelles Testen – nicht automatisierbar, aber unverzichtbar.

Ein Unit Test prüft eine einzelne, isolierte Funktion – ohne Abhängigkeiten von aussen (kein Browser, keine API, keine Datenbank).

 Vitest – Unit Test Screenshot Screenshot Vitest-Output im Terminal mit grünem PASS

Werkzeug: Vitest

Beispiel: Eine Funktion, die langen Text abkürzt.

// textHelpers.js
export function truncateText(text, maxLength) {
  if (text.length <= maxLength) return text
  return text.slice(0, maxLength) + '...'
}
// textHelpers.spec.js
import { truncateText } from './textHelpers.js'
import { test, expect } from 'vitest'
 
test('kürzt langen Text ab', () => {
  expect(truncateText('Was ist Vue.js?', 6)).toBe('Was is...')
})
 
test('lässt kurzen Text unverändert', () => {
  expect(truncateText('Hallo', 10)).toBe('Hallo')
})
Eigenschaft Unit Test
Geschwindigkeit Sehr schnell (Millisekunden)
Browser nötig? Nein
Echte API nötig? Nein
Testet Eine einzelne Funktion

Ein Integration Test prüft das Zusammenspiel mehrerer Teile – zum Beispiel wie eine Funktion einen API-Aufruf durchführt und die Antwort verarbeitet.

 Vitest – Integration Test
Vitest mit Integration Test

Werkzeug: Vitest

Beispiel: Die fetchFaqs()-Funktion abrufen und prüfen, ob die Daten korrekt ankommen.

// fetchFaqs.spec.js
import { test, expect, vi } from 'vitest'
import { fetchFaqs } from './fetchFaqs.js'
 
vi.stubGlobal('fetch', () => Promise.resolve({
  json: () => Promise.resolve([{ id: '1', question: 'Was ist Vue?' }])
}))
 
test('gibt FAQ-Daten zurück', async () => {
  const data = await fetchFaqs('https://mockapi.io/faqs')
  expect(data[0].question).toBe('Was ist Vue?')
})

Warum fetch mocken? Im Test soll nicht die echte MockAPI.io aufgerufen werden. Mit vi.stubGlobal wird fetch durch eine Fake-Version ersetzt, die sofort antwortet – ohne Internetverbindung.

Eigenschaft Integration Test
Geschwindigkeit Schnell (Millisekunden)
Browser nötig? Nein
Echte API nötig? Nein (gemockt)
Testet Fetch + Datenverarbeitung zusammen

Ein E2E Test öffnet einen echten Browser und simuliert, wie eine Nutzerin oder ein Nutzer mit der App interagiert – Klicks, Formular-Eingaben, Navigation.

 Playwright – UI mit laufendem Test
Screenshot Playwright Test Runner mit Browserfenster und Testergebnis

Werkzeug: Playwright

Beispiel: Prüfen, ob das FAQ-Accordion korrekt öffnet und schliesst.

// accordion.spec.js
import { test, expect } from '@playwright/test'
 
test.beforeEach(async ({ page }) => {
  await page.goto('http://localhost:5173', { waitUntil: 'networkidle' })
})
 
test('Antwort ist standardmässig nicht sichtbar', async ({ page }) => {
  await expect(
    page.getByText('Your laptop has absorbed your energy...')
  ).not.toBeVisible()
})
 
test('Antwort erscheint nach Klick auf die Frage', async ({ page }) => {
  await page
    .getByRole('button', { name: 'Why does my code work on my machine?' })
    .click()
  await expect(
    page.getByText('Your laptop has absorbed your energy...')
  ).toBeVisible()
})
Eigenschaft E2E Test
Geschwindigkeit Langsam (Sekunden pro Test)
Browser nötig? Ja (Chromium, Firefox, WebKit)
Echte API nötig? Ja (oder Staging-URL)
Testet Vollständige Interaktion eines Users im Browser

Manuelles Testen kann nicht vollständig automatisiert werden – es erfordert menschliches Urteilsvermögen. Typische Aufgaben:

  • Responsive Design auf verschiedenen Bildschirmgrössen prüfen
  • Cross-Browser-Kompatibilität testen (Chrome, Firefox, Edge)
  • Visuelle Qualität und Nutzererlebnis beurteilen
  • Accessibility mit Tastatur und Screenreader prüfen

 Chrome DevTools – Responsive Design Mode
Screenshot Chrome DevTools mit aktivierter Device Toolbar

Werkzeug: Chrome DevTools (im Browser integriert)

Öffnen Sie die DevTools mit F12, dann klicken Sie auf das Geräte-Symbol oben links oder drücken Sie Ctrl+Shift+M. Sie können nun die Breite frei einstellen oder ein Gerät aus der Liste wählen.

Empfohlene Testbreiten:

Gerät Breite
Mobile (z.B. iPhone SE) bis 375px
Tablet (z.B. iPad) 768px
Desktop ab 1280px

Für das manuelle Testen wird ein Testprotokoll geführt. Es dokumentiert, was getestet wurde, was erwartet wurde und was tatsächlich passiert ist.

# Testfall Erwartetes Resultat Effektives Resultat Status
1 Seite aufrufen FAQ-Liste wird geladen und angezeigt ☐ ✅ ☐ ❌
2 Auf eine Frage klicken Antwort wird sichtbar ☐ ✅ ☐ ❌
3 Nochmals auf dieselbe Frage klicken Antwort schliesst sich ☐ ✅ ☐ ❌
4 Tab-Taste: durch Fragen navigieren Fokus-Rahmen springt sichtbar von Frage zu Frage ☐ ✅ ☐ ❌
5 Enter auf fokussierter Frage Antwort öffnet sich ☐ ✅ ☐ ❌
6 DevTools: 375 px Layout passt sich an, kein horizontales Scrollen ☐ ✅ ☐ ❌
7 Echtes Smartphone App funktioniert, Klick öffnet die Antwort ☐ ✅ ☐ ❌
8 Firefox oder Edge App lädt und verhält sich gleich wie in Chrome ☐ ✅ ☐ ❌
  • de/modul/m291/learningunits/lu16/theorie/b_testing.1782681221.txt.gz
  • Zuletzt geändert: 2026/06/28 23:13
  • von gkoch