Testare il backend di un'applicazione web è una parte critica del processo di sviluppo e di qualsiasi monitoraggio continuo. Consulta anche il test del frontend.
Sviluppo basato su test
Nello sviluppo basato su test (TDD), i requisiti dell'applicazione vengono tradotti in scenari di test prima che l'applicazione venga completamente implementata. In fase di sviluppo, questi test vengono scritti prima e poi implementati durante la creazione dell'applicazione. Requisiti chiari (ad es. scenari di test) assicurano che il codice finale sia ben strutturato, che soddisfi tutti i requisiti e che sia corretto, il che è particolarmente importante nelle prime fasi dello sviluppo.
Integrazione continua e test automatici
I test di integrazione continua (CI) eseguono automaticamente test rispetto a qualsiasi modifica al codice, ad esempio durante le revisioni del codice o quando il codice è stato unito nel repository del codice. I test automatici migliorano la qualità e l'affidabilità complessive del codice inviato riducendo i rischi di rotture o regressioni durante lo sviluppo. Ti consigliamo di configurare un sistema di test automatizzato per il tuo ambiente al fine di garantire l'integrità dell'applicazione. Utilizza un sistema supportato dalla tua architettura, dalla tua piattaforma e dal tuo linguaggio e perfettamente integrato nella tua pipeline di sviluppo. Ad esempio, utilizza GitHub Actions for a CI di lavoro o una pipeline CI personalizzata integrata nel cloud e personalizzata in base alla tua configurazione.
Scopri di più sui principi alla base dei test automatici e su come migliorare i tuoi test. Scopri di più sui test di integrazione continua e sulle best practice per l'implementazione, la configurazione e la misurazione del successo.
Come passaggio successivo, considera una pipeline di distribuzione continua (CD) automatizzata per eseguire automaticamente il deployment delle modifiche e degli aggiornamenti dell'applicazione.
Test delle unità
Il test delle unità si riferisce al test isolato di piccole parti indipendenti di codice. Utilizza un framework di test delle unità consigliato e popolare per il linguaggio o il framework di backend. Ad esempio, per un'applicazione monolitica basata su Java, utilizza JUnit oppure per un'applicazione serverless basata su JavaScript (tra cui Dart o TypeScript), utilizza un framework creato per i test JavaScript, come Jest.
La maggior parte dei framework di backend moderni dispone di risorse dedicate per i test. Valuta la possibilità di integrare queste funzionalità nella tua pipeline CI per automatizzare i test. Assicurati che i test delle unità forniscano una buona copertura del codice della tua applicazione. La maggior parte dei framework di test offre funzionalità per analizzare e generare report sulla copertura dei test e consentire l'integrazione nella pipeline di build.
Test di integrazione
I test di integrazione si riferiscono al test congiunto di moduli o parti dell'applicazione più grandi. Rispetto ai test delle unità (che si concentrano sulle singole parti di codice), i test di integrazione si concentrano sull'integrazione delle singole parti dell'architettura. Ciò può includere anche flussi end-to-end che coprono più passaggi e moduli nell'applicazione.
I test di integrazione possono riguardare diversi moduli dell'applicazione che potrebbero richiedere l'interazione con servizi esterni, ad esempio archiviazione di dati, file system o pagamenti. Valuta la possibilità di strutturare la tua applicazione in modo da supportare le astrazioni per questi servizi tramite l'inserimento di dipendenze o funzionalità simili fornite dal framework di backend.
Test di comportamento e funzionale
Avvicinandosi al backend (o ai singoli moduli o componenti) come un riquadro opaco, i test funzionali si concentrano sull'input e sull'output del sistema. Sebbene i test comportamentali possano essere più comuni per il frontend, svolgono anche un ruolo vitale nel confermare l'integrità end-to-end di un sistema di backend. Questi tipi di test confermano che il sistema reagisce e si comporta come previsto a input diversi.
Test di regressione
I test di regressione si riferiscono a test che confermano che l'applicazione continua a comportarsi come previsto. I test completati correttamente in precedenza vengono eseguiti nuovamente per eventuali nuove modifiche per garantire che le modifiche non abbiano reintrodotto alcun problema precedente. Man mano che i bug vengono corretti in un'applicazione, è necessario aggiungere test delle unità o di integrazione per evitare che il bug si ripeta. I test di regressione dovrebbero essere integrati nei normali test e creare pipeline.
Test del fumo
I test di fumo, chiamati anche test di verifica della build, sono incentrati sulla verifica delle funzioni più critiche dell'applicazione di backend. Oltre ai test di integrazione, che astrae alcune funzionalità e dipendenze esterne, i test del fumo coprono i casi d'uso critici della tua applicazione. Il test del fumo può fungere da livello aggiuntivo di verifica prima di promuovere un'applicazione nell'ambiente di gestione temporanea, in modo da garantire un comportamento accurato. I test del fumo possono consistere di test delle unità automatici o test funzionali manuali condotti da un team QA.
Ambienti di produzione e gestione temporanea
Un ambiente di gestione temporanea è una copia dell'ambiente di produzione, configurata tramite sandbox per semplificare i test. Un deployment dedicato riduce il rischio di problemi con l'ambiente di produzione e semplifica l'esecuzione del controllo di qualità. L'ambiente di gestione temporanea consente di testare un sistema vicino all'ambiente di produzione pubblicato.
Avere una copia 1:1 dell'ambiente di produzione potrebbe non essere fattibile a causa di fattori come i costi o la complessità dell'architettura di backend. Valuta quali parti del backend sono più critiche e ottimizzale per un ambiente di gestione temporanea.
I test sui dati utilizzati in produzione offrono un grande vantaggio nel testare il comportamento dell'applicazione con i dati reali. Assicurati di considerare le implicazioni sulla privacy e le esigenze di archiviazione dei dati per un ambiente temporaneo di questo tipo e progetta con attenzione i dati utilizzati dal tuo sistema di backend. L'accesso a un ambiente di questo tipo deve essere strettamente controllato, soprattutto se vengono utilizzati dati di produzione.
Considera la portata del tuo sistema e se un ambiente in piedi è appropriato per la tua applicazione. Gli ambienti temporanei in sequenza, di cui è possibile eseguire automaticamente il deployment tramite un sistema di distribuzione continua, offrono ulteriori opportunità di testare le build giornaliere o settimanali e sottoporle a ulteriori controlli prima del rilascio.
Un altro approccio è quello di fare maggiore affidamento su test di integrazione continua e sistemi automatici, piuttosto che su un ambiente temporaneo con deployment completo. Tieni conto del flusso di lavoro, dell'integrità del sistema, della copertura del codice e dei requisiti tecnici del tuo team.