CI CD og Testing - idatt2106-v25-02/krisefikser GitHub Wiki
🧪 CI/CD og Testing
Teststrategi
Vår teststrategi er utformet for å sikre at Krisefikser-applikasjonen er pålitelig, robust og brukervennlig. Vi har valgt å fokusere på:
- Automatiserte tester som en del av CI/CD-pipelinen vår
- Omfattende dekning av kritiske deler av kodebasen (business logic)
- Forskjellige testtyper for å fange ulike typer feil
Testtyper
backend (Java / Spring boot)
-
Enhetstester
- Tester individuelle komponenter i isolasjon
- Fokus på service klasser og repositories
-
Integrasjonstester
- Tester samspillet mellom flere komponenter
- Fokus på API-endepunkter og database interaksjoner
Frontend (Vue)
-
Engetstester (Vitest)
- Tester individuelle Vue komponenter
- Bruker
@vue/test-utils
og vitest
-
E2E-tester (Cypress)
- Tester hele applikasjonen fra brukerens perspektiv
Dekningsgrad
I samsvar med kravene i visjonsdokumentet streber vi etter:
Backend
- Mål: Minst 50% testdekning
- JaCoCo-rapport genereres for hver gjennom gang av CI
- Fokusert dekning på kritiske komponenter som:
- Autentisering og autorisering
- Forretningslogikk
Frontend
- Mål: Minst 30% testdekning
- Hovedfokus på enhetstester av sentrale vue komponenter som blir hyppig gjenbrukt
- Kritiske brukerflyter dekkes av E2E-tester
I tillegg til tester har vi satt opp en typesafe REST-api, dette gjør det enkelt å holde frontend og backend i sync, ettersom frontend ikke vil bygge uten at den er oppdatert med OpenAPI-schemaen generert fra backend
CI
Vårt CI system er konfigurert i GitHub actions og inkluderer:
1. Backend CI
- Kjører kodelinting og formatering med Google Java Format
- Bygger med maven
- Kjører alle tester med test profil
- Genererer JaCoCo-rapport som lagres som et artifact
2. Frontend CI
- Installerer dependencies med PNPM
- Bygger frontend
- Kjører linting
- Kjører tester
CI-pipelinen kan man finne ved .github/workflows/ci.yml
og kjøres automatisk ved:
- Push til
main
ellerdevelop
- Pull request mot
main
ellerdevelop
I tillegg til vår generelle CI-pipeline, har vi også en egen pipeline for å generere velocity charts, denne finner man på .github/workflows/velocity_chart.yml
CD
Applikasjonen vår har kontinuerlig distribusjon gjennom Railway
. Plattformen er integrert med en webhook som er koblet til vårt repository, og denne varsler om ny release. Ved hver nye release bygger Railway
både backend og frontend ut ifra deres respektive Docker-filer som ligger henholdsvis i roten av frontend og backend mappene. Siden vi bruker miljøvariabler for å konfigurere tilkobling av backend, kan vi både kjøre frontend og backend lokalt, og i railway
, uten problemer.