Zo gebruik je Checksum voor continu end-to-end testen in CI/CD

End-to-endtests (E2E) uitvoeren in CI/CD werkt alleen als je testsuite met je applicatie kan meegroeien. Naarmate je product verandert, kan het handmatig maken van nieuwe tests en herstellen van defecte tests al snel de bottleneck worden die elke release vertraagt.

Checksum is ontwikkeld om een groot deel van dat proces te automatiseren. 

Deze handleiding laat zien hoe je Checksum met je omgeving en repository verbindt, Playwright-tests in je CI/CD-pipeline genereert en uitvoert, en autonoom onderhoud inschakelt terwijl je applicatie zich ontwikkelt.

Hoe Checksum doorlopend E2E-testen ondersteunt

Checksum ondersteunt doorlopend E2E-testen via een continue workflow:

1. Instellen: Verbindt je repository en testomgeving.
2. Detecteren: Analyseert je applicatie en identificeert de belangrijkste gebruikersflows om te testen.
3. Genereren: Maakt productierijpe Playwright-tests en levert deze als pull requests aan je repository.
4. Uitvoeren: Voert deze tests lokaal of in je CI/CD-pipeline uit, terwijl automatisch herstel tijdelijke fouten tijdens de uitvoering probeert op te lossen.
5. Herstellen: Werkt defecte Playwright-tests bij wanneer je applicatie verandert en opent een pull request met de voorgestelde oplossing.
6. Monitoren: Houdt de teststatus bij en waarschuwt je team wanneer problemen aandacht vereisen.

Omdat elke test standaard Playwright-code is, behoud je het volledige eigendom en kun je de testsuite met of zonder Checksum uitvoeren.

Vereisten voor doorlopend E2E-testen in Checksum

Voordat je Checksum instelt voor doorlopend E2E-testen, moet je ervoor zorgen dat het volgende gereed is.

Een acceptatie- of productieachtige omgeving

Checksum test tegen een live applicatie. Daarom heb je een toegankelijke acceptatie- of productieachtige omgeving met een Omgevings-URL nodig. Als je applicatie authenticatie vereist, configureer je een Inlog-URL en verstrek je testgebruikersgegevens die Checksum kan gebruiken om in te loggen en de gebruikersflows van je applicatie te analyseren.

Een verbonden repository en CI-pipeline

Verbind je GitHub- of GitLab-repository zodat Checksum je codebase kan analyseren en pull requests kan maken met gegenereerde of bijgewerkte Playwright-tests. Als je tests in een aparte repository staan, verbetert het verbinden van zowel de bronrepository als de testrepository de nauwkeurigheid van de flowdetectie.

Je hebt ook een CI-platform nodig om je tests uit te voeren. Checksum biedt ingebouwde ondersteuning voor GitHub Actions en GitLab CI/CD, terwijl andere CI-platforms kunnen worden geïntegreerd via de Checksum CLI of openbare API.

Een Checksum-project en API-sleutel

Maak een Checksum-project aan in de webapp en genereer een Project-API-sleutel via Projectinstellingen. De API-sleutel authenticeert de Checksum CLI en stelt je CI-pipeline in staat de omgevingsvariabelen te downloaden die nodig zijn om je tests uit te voeren.

Als je een uitgebreidere uitleg van het eerste installatieproces wilt, kun je ook {{deeplink:154034:[de pagina Aan de slag van Checksum]:getting_started}} bezoeken.

Hoe je doorlopend E2E-testen uitvoert in Checksum

Bij de onderstaande stappen wordt ervan uitgegaan dat je een Checksum-project hebt aangemaakt en je API-sleutel bij de hand hebt.

Stap 1. Verbind je omgeving en repository

Stel in de installatiewizard van de webapp je Omgevings-URL (bijv. https://staging.myapp.com) en Inlog-URL in en voeg de gegevens van de testgebruiker toe waarmee Checksum zich zal authenticeren. 

Installeer vervolgens de Git-app voor GitHub of GitLab, zodat Checksum je code kan lezen en PR's kan openen. Als je tests naast je broncode komen te staan, verbind je voor beide dezelfde repository.

Stap 2. Initialiseer je testrepository

Maak (of wijs) een repo voor je tests aan en initialiseer deze met de CLI:

mkdir my-checksum-tests && cd my-checksum-tests

npm init -y

npm install @checksum-ai/runtime playwright

npx checksumai init

Hiermee wordt een map checksum/ aangemaakt met configuratie, een Playwright-configuratie en een voorbeeldtest. Controleer de koppeling voordat je verdergaat:

npm install

npx playwright install --with-deps

npx checksumai dotenv --download --api-key=<YOUR_API_KEY>

npx checksumai test -g "example"

De voorbeeldtest bevestigt dat het inloggen werkt in jouw omgeving. Een groen resultaat betekent dat je klaar bent om echte flows te detecteren.

Stap 3. Laat de agent kritieke gebruikersflows detecteren

Start een detectiesessie en laat de E2E-agent je applicatie analyseren om belangrijke gebruikersflows te identificeren. Bekijk na afloop van de detectie de voorgestelde flows en geef prioriteit aan de flows die het relevantst zijn voor je release voordat je tests genereert.

Stap 4. Genereer Playwright-tests die klaar zijn voor productie

Genereer Playwright-tests voor de flows die je hebt geselecteerd. 

De agent plant, implementeert, beoordeelt en verifieert elke test voordat er een pull request wordt geopend met een voor mensen leesbaar storybestand en de Playwright-test. 

Beoordeel de pull request zoals elke andere codewijziging en voeg vervolgens de tests die je aan je suite wilt toevoegen samen.

Stap 5. Koppel tests aan je CI/CD-pijplijn

Gebruik je GitHub Actions, sla je API-sleutel en omgevingswaarden dan op als repositorygeheimen en voeg je een workflow toe die Playwright installeert, het Checksum-env-bestand downloadt en de suite uitvoert:

name: Checksum-tests uitvoeren
on:
  workflow_dispatch:        # handmatige trigger om te starten
  # schedule:
  #   - cron: '0 0 * * *'   # elke nacht, zodra geverifieerd
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: npm-afhankelijkheden installeren
        run: npm install
      - name: Playwright met afhankelijkheden installeren
        run: npx playwright install --with-deps
      - name: .env downloaden van Checksum
        run: npx checksumai dotenv --download --api-key="${{ secrets.CHECKSUM_API_KEY }}"
      - name: Checksum-tests uitvoeren
        run: npx checksumai test
        env:
          CHECKSUM_API_KEY: ${{ secrets.CHECKSUM_API_KEY }}
          USERNAME: ${{ secrets.USERNAME }}
          PASSWORD: ${{ secrets.PASSWORD }}
          LOGIN_URL: ${{ secrets.LOGIN_URL }}
          BASE_URL: ${{ secrets.BASE_URL }}
          CI: true

GitLab CI/CD volgt dezelfde opzet in .gitlab-ci.yml. Begin met een handmatige trigger (workflow_dispatch / when: manual) om te bevestigen dat de uitvoering goed verloopt en stap vervolgens over op een schema voor nachtelijke gezondheidscontroles of een merge-trigger om na implementaties te verifiëren.

Stap 6. Voeg uitvoeringen per PR toe en schakel autonome reparatie in

Als je wilt dat Checksum tests uitvoert voor elke pull request, gebruik je de officiële GitHub Action in plaats van de CLI op je eigen runner uit te voeren. Dit is handig om de wijzigingen in elke pull request te valideren.

name: Checksum-tests
on: pull_request
permissions:
  contents: read
  pull-requests: read
jobs:
  checksum:
    runs-on: ubuntu-latest
    steps:
      - uses: checksum-ai/test-run-action@v1
        with:
          api-key: ${{ secrets.CHECKSUM_API_KEY }}
          grep: 'checkout'
          auto-heal: true

De grep-optie filtert op naam welke tests worden uitgevoerd, terwijl auto-heal: true automatische reparatie inschakelt wanneer een test mislukt. 

Standaard wordt de workflow beëindigd nadat de uitvoering is geaccepteerd en worden de resultaten als opmerking op de pull request geplaatst. Als je wilt dat de workflow wacht op het eindresultaat en op basis daarvan slaagt of mislukt, stel je wait: true in.

Met automatisch herstel ingeschakeld probeert Checksum tijdens de testrun in realtime herstel uit te voeren. Als de test nog steeds mislukt, werkt het de Playwright-test bij, opent het een pull request met de voorgestelde oplossing en plaatst het de voortgang als opmerking bij het oorspronkelijke pull request. 

Je team kan de wijzigingen vervolgens net als elke andere codebijdrage beoordelen en mergen.

Hoe succesvol continu E2E-testen eruitziet

Zodra Checksum in je CI/CD-pijplijn is geïntegreerd, kun je het volgende verwachten:

• Je E2E-testsuite wordt automatisch uitgevoerd op basis van de trigger die je hebt geconfigureerd, waaronder pull requests, geplande uitvoeringen en implementaties.
• Nieuwe gebruikersstromen worden gedetecteerd en omgezet in Playwright-tests zonder dat je elke test handmatig hoeft te schrijven.
• Testfouten die worden veroorzaakt door wijzigingen in de applicatie worden opgelost via automatisch herstel of automatische reparatie voordat handmatige updates nodig zijn.
• Je team besteedt minder tijd aan het onderhouden van Playwright-tests en meer tijd aan het beoordelen van betekenisvolle testwijzigingen die via pull requests worden aangeleverd.

Om de gezondheid van je implementatie te meten, houd je het slagingspercentage van je tests bij, het percentage tests dat automatisch is gerepareerd, de gemiddelde tijd om testfouten op te lossen en het percentage fout-positieve resultaten. 

Deze statistieken helpen je te begrijpen hoe betrouwbaar je E2E-testsuite draait naarmate je applicatie zich ontwikkelt. Als je je resultaten wilt vergelijken met productiestandaarden, biedt {{deeplink:154034:[Checksum-rapport over QA-benchmarks]:qa_benchmark}} gegevens voor deze statistieken op basis van meer dan 1 miljoen echte productieruns.

Veelgemaakte fouten bij continu E2E-testen en tips van experts

Zelfs met de juiste configuratie kunnen enkele veelgemaakte fouten de kwaliteit, uitvoering en het onderhoud van tests beïnvloeden. Dit zijn de zaken waarop je moet letten en hoe je ze voorkomt.

Tests uitvoeren in een instabiele omgeving

Als je testresultaten inconsistent zijn of mislukken voordat een betekenisvolle testuitvoering begint, is je testomgeving mogelijk nog niet klaar. Zorg ervoor dat je stagingomgeving of productieachtige omgeving stabiel is, dat de inloggegevens van je testgebruiker correct werken en dat de voorbeeldtest slaagt voordat je aanvullende dekking genereert.

Te veel gebruikersstromen genereren

Checksum identificeert mogelijk meer gebruikersstromen dan je aanvankelijk nodig hebt. Tests genereren voor elke kandidaat verhoogt de uitvoeringstijd en de beoordelingsinspanning. Begin met de workflows die het belangrijkst zijn voor je releases en breid de dekking daarna geleidelijk uit.

Gegenereerde tests mergen zonder beoordeling

Gegenereerde en gerepareerde tests worden als pull requests aangeleverd, zodat je team elke wijziging kan valideren voordat deze onderdeel wordt van de testsuite. Beoordeel nieuwe tests zorgvuldig tijdens de eerste fasen van de ingebruikname en bouw na verloop van tijd vertrouwen op in het generatieproces.

Je pijplijn te vroeg automatiseren

Voordat je uitvoeringen plant of tests voor elk pull request activeert, moet je bevestigen dat je pijplijn stabiel is bij handmatige uitvoeringen. Zodra je consistent betrouwbare resultaten krijgt, kun je de werkstroom met meer vertrouwen automatiseren.

Elk pull request blokkeren

Als je wait: true inschakelt, wacht de werkstroom totdat de testrun is voltooid voordat deze wordt afgerond. Gebruik dit alleen voor werkstromen die een merge moeten blokkeren. Voor alle andere werkstromen biedt de standaardopmerking bij het pull request feedback zonder CI-agents bezet te houden.

Conclusie

Je hebt nu gezien hoe Checksum in een werkstroom voor continu E2E-testen past: van het verbinden van je omgeving en repository tot het genereren van Playwright-tests, het integreren ervan in je CI/CD-pijplijn en het inschakelen van autonoom onderhoud. 

Naarmate je applicatie zich ontwikkelt, helpt Checksum je E2E-testsuite betrouwbaar te houden zonder hetzelfde niveau van handmatig onderhoud toe te voegen.

Als je het platform verder wilt verkennen, kun je onze uitgebreide Checksum-beoordeling lezen om meer te weten te komen over de mogelijkheden ervan, of bekijken hoe Checksum met je eigen applicatie werkt door {{deeplink:154034:[rechtstreeks contact op te nemen met hun team.]:end_to_end}}