Læringsmål
- Bruge DevTools Network til status, headers og CORS-fejl.
- Sætte breakpoints i Razor og services (Blazor Server).
- Skrive en minimal testplan med forventet/faktisk resultat.
- Gennemføre 5-min usability-test med én opgave.
Hvornår stoppe og dokumentere? Når et flow virker manuelt — skriv testplan med screenshots af Network (200/401) før I går videre til næste feature.
Tjek dig selv før du går videre
- Du kan bruge DevTools Network til at fejlsøge API-kald.
- Du har en kort testplan for et CRUD-flow.
- Du kan udføre usability-tjek på egen app.
Debug-checkliste
- Reproducer — hvilken route, hvilket klik, hvilken bruger/nøgle?
- Network — gik request af sted? Status 200/401/404? Response body?
- Console — JS fejl, WebSocket/SignalR disconnect?
- Application — sessionStorage: token/nøgle sat?
- Visual Studio — breakpoint i
OnInitializedAsynceller service. - Log — midlertidig
Console.WriteLineeller ILogger (Server).
Regel: UI-symptom → bevis i Network → derefter ændr kode. Gæt ikke DTO-felter uden at åbne Response.
Network-fanen — trin for trin
Åbn F12 → Network → filtrer Fetch/XHR. Klik «Hent Pokémon» i jeres app:
- Tjek Request URL — korrekt base + path?
- Tjek Request Headers —
X-Api-KeyellerAuthorizationmed? - Tjek Response — JSON array eller fejlbesked?
- Rød linje med CORS — origin ikke tilladt på API; fix på server eller proxy via egen backend.
// Midlertidig diagnostic i service
_logger.LogInformation("Henter pokemon limit={Limit}", limit);
var response = await _http.GetAsync(url);
_logger.LogWarning("Status {Code}", response.StatusCode);
Typiske «tom UI»-årsager
- Deserialisering fejler silently — property navne matcher ikke JSON
- 401 — glemt API-nøgle til LoL
- Exception i async metode uden try/catch — tjek Server-log
- Render mode — komponent ikke interaktiv, handler kører ikke
Elev-fejl → symptom → fix: Liste binding til forkert property (results vs items) — symptom: Network 200, UI tom. Fix: breakpoint efter deserialize, tjek count.
Faldgrube: At debugge kun i UI uden at læse response body — I ser «ingen fejl» mens API returnerer {"error":"..."} med status 400.
Test-dokumentation (let vægt)
Tabel eller liste pr. feature:
| ID | Givet | When | Then | Resultat |
|---|---|---|---|---|
| T1 | Gyldig API-nøgle | Åbn /lol | Champion-liste vises | OK / fail + screenshot |
| T2 | Ingen nøgle | Åbn /lol | Fejlbesked 401 | … |
| T3 | Query name=pi | Submit søg | Min 2 tegn validering | … |
Hvornår screenshot? Ved 401/503 og ved valid submit — censor skal se både UI og Network uden at køre jeres maskine.
Usability-script (5 min)
Instruktion til testperson (uden hjælp):
«Du skal finde Pokémon #25 og gemme den som favorit. Sig højt hvad du forventer sker.»
Observer: hvor mange klik, hvor de leder efter menu, om loading feedback mangler. Notér 3 forbedringspunkter.
Quiz 1
UI viser tom liste — første tekniske skridt?
Quiz 2
Hvad dokumenterer en god testplan-minimum til eksamen?
Hvorfor det betyder noget: Eksamen og projekt beder om dokumenteret test — Network-fanen beviser om fejl er UI eller API.
Sådan fejler det i praksis: «Det virker på min maskine» uden testplan for 401/nøgle — dyrt i demo for censor.
Mini-opgave
5-trins testplan: nøgle → Pokémon 200 → LoL 401 → LoL 200 → lokal logout.
Quiz 3
401 mod LoL — første skridt?
Læs hos Microsoft
Prøv med API
- Debug et kald i Network mens I bruger Pokémon-demo — sammenlign headers med jeres Blazor-app.
- Kør usability-script på klassekammerat med jeres prototype.
Baseret på MAGS Blazor-wiki og Microsoft Learn — Blazor.