Di seguito sono riportate alcune forme tipiche di automazione che potresti voler utilizzare nel tuo sistema CI.
Job di base
Creazione: creando un progetto da zero, ti assicuri che le nuove modifiche vengano compilate correttamente e che tutti gli strumenti e le librerie siano compatibili tra loro.
Controllo lint o stile: questo passaggio è facoltativo, ma consigliato. Quando applichi regole di stile ed esegui analisi statiche, le revisioni del codice possono essere più concise e mirate.
Test locali o lato host: vengono eseguiti sulla macchina locale che esegue la build. Su Android di solito si tratta della JVM, perciò sono veloci e affidabili. Includono anche test Robolectric.
Test strumentali
I test eseguiti su emulatori o dispositivi fisici richiedono un certo provisioning, attendere che i dispositivi si avviino o siano connessi e altre operazioni che aggiungano complessità.
Sono disponibili diverse opzioni per eseguire test strumentati su CI:
- Puoi utilizzare Gradle Managed Devices per definire i dispositivi da utilizzare (ad esempio "emulatore Pixel 2 sull'API 27") e gestire il provisioning dei dispositivi.
- La maggior parte dei sistemi CI è dotata di un plug-in di terze parti (chiamato anche "azione", "integrazione" o "passaggio") per gestire gli emulatori Android.
- Delega i test strumentati a una device farm come Firebase Test Lab. Le device farm vengono utilizzate per la loro elevata affidabilità e possono essere eseguite su emulatori o dispositivi fisici.
Test di regressione delle prestazioni
Per monitorare le prestazioni dell'app, consigliamo di utilizzare le librerie di benchmark. L'automazione dei test delle prestazioni durante lo sviluppo richiede dispositivi fisici per garantire risultati dei test coerenti e realistici.
L'esecuzione dei benchmark può richiedere molto tempo, soprattutto in presenza di un'elevata copertura del codice e dei percorsi degli utenti di cui stai effettuando il benchmarking. Anziché eseguire tutti i benchmark per ogni funzionalità o commit unito, valuta la possibilità di eseguirli come parte di una build di manutenzione pianificata regolarmente, ad esempio una build notturna.
Monitoraggio del rendimento
Puoi monitorare le regressioni del rendimento utilizzando la funzionalità di adattamento. Stepfitting definisce una finestra temporale continuata dei risultati della build precedente confrontati con la build attuale. Questo approccio combina diversi risultati di benchmark in un'unica metrica specifica per la regressione. Puoi applicare l'adattamento dei passaggi per ridurre il rumore durante i test di regressione.
Questo riduce il numero di falsi positivi che possono verificarsi quando i tempi del benchmark sono lenti per una singola build e poi si normalizzano di nuovo.
Testa i controlli di regressione della copertura
La copertura dei test è una metrica che può aiutare te e il tuo team a decidere se i test coprono sufficientemente una variazione. Tuttavia, non dovrebbe essere l'unico indicatore. È pratica comune configurare un controllo di regressione che non va a buon fine o mostra un avviso quando la copertura diminuisce rispetto al ramo di base.