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 eller develop
  • Pull request mot main eller develop

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.

🔙 Tilbake til Dokumentasjonssiden