Come usare Checksum per i test completi continui in CI/CD

Eseguire test end-to-end (E2E) in CI/CD funziona solo se la suite di test è in grado di evolversi insieme alla tua applicazione. Quando il prodotto cambia, creare manualmente nuovi test e correggere quelli non più funzionanti può rapidamente diventare il collo di bottiglia che rallenta ogni rilascio.

Checksum è progettato per automatizzare gran parte di questo processo. 

Questa guida mostra come collegare Checksum al tuo ambiente e al tuo repository, generare ed eseguire test Playwright nella tua pipeline CI/CD e abilitare la manutenzione autonoma man mano che la tua applicazione evolve.

Come Checksum supporta i test E2E continui

Checksum supporta i test E2E continui attraverso un flusso di lavoro continuo:

1. Configurazione: collega il tuo repository e l'ambiente di test.
2. Rilevamento: analizza la tua applicazione e identifica i flussi utente più importanti da testare.
3. Generazione: crea test Playwright pronti per la produzione e li distribuisce come richieste pull nel tuo repository.
4. Esecuzione: esegue questi test localmente o nella tua pipeline CI/CD, mentre il ripristino automatico tenta di risolvere gli errori temporanei durante l'esecuzione.
5. Correzione: aggiorna i test Playwright non più funzionanti quando la tua applicazione cambia e apre una richiesta pull con la correzione proposta.
6. Monitoraggio: tiene traccia dello stato dei test e avvisa il tuo team quando è necessario intervenire.

Poiché ogni test è codice Playwright standard, mantieni il pieno controllo e puoi eseguire la suite con o senza Checksum.

Prerequisiti per i test E2E continui in Checksum

Prima di configurare Checksum per i test E2E continui, assicurati che siano pronti gli elementi seguenti.

Un ambiente di staging o simile a quello di produzione

Checksum esegue i test su un'applicazione attiva, quindi ti servirà un ambiente di staging o simile a quello di produzione accessibile, con un URL dell'ambiente. Se la tua applicazione richiede l'autenticazione, configura un URL di accesso e fornisci le credenziali di un utente di test che Checksum possa utilizzare per effettuare l'accesso e analizzare i flussi utente della tua applicazione.

Un repository collegato e una pipeline CI

Collega il tuo repository GitHub o GitLab in modo che Checksum possa analizzare la tua base di codice e creare richieste pull contenenti test Playwright generati o aggiornati. Se i tuoi test si trovano in un repository separato, collegare sia il repository sorgente sia quello dei test migliora la precisione del rilevamento dei flussi.

Ti servirà anche una piattaforma CI per eseguire i test. Checksum offre il supporto integrato per GitHub Actions e GitLab CI/CD, mentre le altre piattaforme CI possono essere integrate tramite la CLI di Checksum o l'API pubblica.

Un progetto Checksum e una chiave API

Crea un progetto Checksum nell'app web e genera una chiave API del progetto dalle impostazioni del progetto. La chiave API autentica la CLI di Checksum e consente alla tua pipeline CI di scaricare le variabili d'ambiente necessarie per eseguire i test.

Se desideri una guida più approfondita al processo di configurazione iniziale, puoi anche visitare {{deeplink:154034:[la pagina Inizia a usare Checksum]:getting_started}}.

Come eseguire test E2E continui in Checksum

I passaggi seguenti presuppongono che tu abbia creato un progetto Checksum e abbia a disposizione la tua chiave API.

Passaggio 1. Collega il tuo ambiente e il repository

Nella procedura guidata di configurazione dell'app web, imposta il tuo URL dell'ambiente (ad esempio https://staging.myapp.com) e l'URL di accesso, quindi aggiungi le credenziali dell'utente di test con cui Checksum effettuerà l'autenticazione. 

Installa quindi l'app Git per GitHub o GitLab, in modo che Checksum possa leggere il tuo codice e aprire richieste pull. Se i tuoi test risiederanno insieme al codice sorgente, collega lo stesso repository per entrambi.

Passaggio 2. Inizializza il repository dei test

Crea (o designa) un repository per i tuoi test e inizializzalo con la CLI:

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

npm init -y

npm install @checksum-ai/runtime playwright

npx checksumai init

Questa procedura crea una cartella checksum/ con la configurazione, una configurazione di Playwright e un test di esempio. Verifica il collegamento prima di procedere:

npm install

npx playwright install --with-deps

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

npx checksumai test -g "example"

Il test di esempio conferma che l'accesso funziona nel tuo ambiente. Un risultato positivo indica che sei pronto a rilevare flussi reali.

Passaggio 3. Lascia che l'agente rilevi i flussi utente critici

Avvia una sessione di rilevamento e lascia che l'agente E2E analizzi la tua applicazione per identificare i flussi utente importanti. Una volta completato il rilevamento, esamina i flussi proposti e assegna la priorità a quelli più rilevanti per la tua release prima di generare i test.

Passaggio 4. Genera test Playwright pronti per la produzione

Genera test Playwright per i flussi che hai selezionato. 

L'agente pianifica, implementa, esamina e verifica ogni test prima di aprire una pull request contenente un file della storia leggibile dall'uomo e il test Playwright. 

Esamina la pull request come qualsiasi altra modifica al codice, quindi unisci i test che sei pronto ad aggiungere alla tua suite.

Passaggio 5. Integra i test nella pipeline CI/CD

Per GitHub Actions, salva la chiave API e i valori dell'ambiente come segreti del repository, quindi aggiungi un flusso di lavoro che installi Playwright, scarichi il file env di Checksum ed esegua la suite:

name: Esegui i test di Checksum
on:
  workflow_dispatch:        # attivazione manuale per avviare l'esecuzione
  # schedule:
  #   - cron: '0 0 * * *'   # ogni notte, dopo la verifica
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Installa le dipendenze npm
        run: npm install
      - name: Installa Playwright con le dipendenze
        run: npx playwright install --with-deps
      - name: Scarica .env da Checksum
        run: npx checksumai dotenv --download --api-key="${{ secrets.CHECKSUM_API_KEY }}"
      - name: Esegui i test di Checksum
        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 segue la stessa struttura nel file .gitlab-ci.yml. Inizia con un'attivazione manuale (workflow_dispatch / when: manual) per confermare che l'esecuzione funzioni correttamente, quindi passa a una pianificazione per i controlli notturni dello stato o a un'attivazione al momento dell'unione per verificare il funzionamento dopo le distribuzioni.

Passaggio 6. Aggiungi esecuzioni per ogni PR e attiva la correzione autonoma

Se vuoi che Checksum esegua i test per ogni pull request, utilizza l'azione GitHub ufficiale invece di eseguire autonomamente la CLI sul tuo runner. È utile per convalidare le modifiche introdotte in ogni pull request.

name: Test di Checksum
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

L'opzione grep filtra i test da eseguire in base al nome, mentre auto-heal: true abilita la correzione automatica quando un test non va a buon fine. 

Per impostazione predefinita, il flusso di lavoro termina dopo l'accettazione dell'esecuzione e pubblica i risultati come commento sulla pull request. Se vuoi che il flusso di lavoro attenda il risultato finale e restituisca un esito positivo o negativo di conseguenza, imposta wait: true.

Con l'autoripristino abilitato, Checksum tenta il recupero in tempo reale durante l'esecuzione del test. Se il test continua a non riuscire, aggiorna il test Playwright, apre una pull request con la correzione proposta e pubblica i progressi come commento sulla pull request originale. 

Il tuo team può quindi esaminare e unire le modifiche come qualsiasi altro contributo al codice.

Come si presenta un test E2E continuo efficace

Una volta integrato Checksum nella pipeline CI/CD, dovresti aspettarti quanto segue:

• La tua suite di test E2E viene eseguita automaticamente in base al trigger configurato, incluse pull request, esecuzioni pianificate e distribuzioni.
• I nuovi flussi utente vengono rilevati e convertiti in test Playwright senza dover scrivere manualmente ogni test.
• I fallimenti dei test causati da modifiche all'applicazione vengono risolti tramite recupero automatico o autoripristino prima che siano necessari aggiornamenti manuali.
• Il tuo team dedica meno tempo alla manutenzione dei test Playwright e più tempo all'esame delle modifiche significative ai test fornite tramite pull request.

Per misurare lo stato della tua implementazione, monitora il tasso di superamento dei test, la percentuale di test ripristinati automaticamente, il tempo medio di risoluzione dei fallimenti dei test e il tasso di falsi positivi. 

Queste metriche ti aiutano a capire con quale affidabilità viene eseguita la tua suite E2E mentre l'applicazione si evolve. Per confrontare i tuoi risultati con i benchmark di produzione, {{deeplink:154034:[il rapporto sui benchmark QA di Checksum]:qa_benchmark}} fornisce dati per queste metriche basati su oltre 1 milione di esecuzioni reali in produzione.

Errori comuni nei test E2E continui e consigli degli esperti

Anche con la configurazione corretta, alcuni errori comuni possono influire sulla qualità, sull'esecuzione e sulla manutenzione dei test. Ecco cosa tenere sotto controllo e come evitarlo.

Eseguire i test in un ambiente instabile

Se i risultati dei test sono incoerenti o i test falliscono prima che inizi un'esecuzione significativa, l'ambiente di test potrebbe non essere pronto. Assicurati che l'ambiente di staging o simile a quello di produzione sia stabile, che le credenziali dell'utente di test funzionino correttamente e che il test di esempio venga superato prima di generare ulteriore copertura.

Generare troppi flussi utente

Checksum potrebbe identificare più flussi utente di quanti ne siano inizialmente necessari. Generare test per ogni candidato aumenta il tempo di esecuzione e l'impegno richiesto per la revisione. Inizia dai flussi di lavoro più importanti per le tue release, quindi amplia gradualmente la copertura.

Unire test generati senza esaminarli

I test generati e ripristinati vengono forniti come pull request, così il tuo team può convalidare ogni modifica prima che diventi parte della suite di test. Esamina attentamente i nuovi test nelle fasi iniziali dell'adozione e acquisisci gradualmente fiducia nel processo di generazione.

Automatizzare la pipeline troppo presto

Prima di pianificare le esecuzioni o attivare i test per ogni pull request, verifica che la pipeline sia stabile con esecuzioni manuali. Una volta ottenuti risultati affidabili con continuità, potrai automatizzare il flusso di lavoro con maggiore sicurezza.

Bloccare ogni pull request

L'abilitazione di wait: true fa sì che il flusso di lavoro attenda il completamento dell'esecuzione del test prima di terminare. Usala solo per i flussi di lavoro che devono bloccare un'unione. Per tutto il resto, il commento predefinito sulla pull request fornisce un riscontro senza impegnare i runner CI.

Conclusione

Ora hai visto come Checksum si inserisce in un flusso di lavoro di test E2E continuo: dalla connessione dell'ambiente e del repository alla generazione dei test Playwright, fino alla loro integrazione nella pipeline CI/CD e all'abilitazione della manutenzione autonoma. 

Man mano che la tua applicazione si evolve, Checksum aiuta a mantenere affidabile la tua suite di test E2E senza aggiungere lo stesso livello di manutenzione manuale.

Se vuoi approfondire la piattaforma, puoi leggere la nostra recensione approfondita di Checksum per saperne di più sulle sue funzionalità, oppure vedere come Checksum funziona con la tua applicazione collegandoti direttamente al {{deeplink:154034:[loro team.]:end_to_end}}