Dev Proxy vs test unitari

Il proxy di sviluppo e gli unit test servono a scopi diversi nella strategia di test. Sebbene entrambi siano utili, testano l'applicazione in modi fondamentalmente diversi. L'uso di questi elementi offre una copertura completa del comportamento dell'applicazione.

Approcci di test diversi

Gli unit test testano parti isolate di codice con dipendenze fittizie. Quando si scrive uno unit test per il codice che chiama un'API, in genere si simula il client HTTP per restituire risposte predefinite. Questo approccio consente di verificare che il codice gestisca correttamente scenari specifici.

Dev Proxy testa l'applicazione in esecuzione con il comportamento simulato dell'API. Invece di simulare il codice, Dev Proxy intercetta le richieste HTTP effettive e simula condizioni reali come errori, limitazione e latenza. Questo approccio testa l'applicazione nel suo complesso, inclusi tutti i livelli tra il codice e l'API.

Quando utilizzare ciascuno

Usare unit test quando si vuole:

• Testare il comportamento specifico della funzione e i casi limite
• Verificare la logica di business in isolamento
• Ottenere commenti e suggerimenti rapidi durante lo sviluppo
• Raggiungere una copertura del codice elevata
• Testare percorsi di gestione degli errori specifici

Usare Dev Proxy quando si vuole:

• Testare l'applicazione in esecuzione end-to-end
• Simulare condizioni difficili da riprodurre, ad esempio problemi di limitazione o di rete
• Testare la logica di ripetizione dei tentativi reali e la gestione degli errori in tutti i livelli
• Esegui l'applicazione sotto carico con errori casuali
• Verificare la resilienza senza modificare il codice

Vantaggi del proxy di sviluppo

Dev Proxy offre diversi vantaggi rispetto ai tradizionali approcci di simulazione:

• Non sono necessarie modifiche al codice. Non è necessario modificare l'applicazione per usare Dev Proxy. Funziona a livello di rete, intercettando le richieste HTTP in modo trasparente.
• Funziona con qualsiasi libreria HTTP. Alcune librerie HTTP sono notoriamente difficili da simulare. Con Dev Proxy, non è importante quale libreria si usa: RestSharp, HttpClient, Axios o qualsiasi altra. Dev Proxy intercetta tutto il traffico HTTP indipendentemente dalla libreria.
• Testa l'applicazione reale. Gli unit test con client HTTP fittizi non testano la logica di ripetizione effettiva dei tentativi, la gestione delle connessioni o il comportamento di timeout. Dev Proxy testa l'applicazione reale con tutte le relative dipendenze.
• Più facile comprendere gli errori. Quando è possibile attivare errori su richiesta in un'applicazione in esecuzione, è più facile comprendere ed eseguire il debug del modo in cui l'applicazione li gestisce.
• Simula condizioni complesse. Dev Proxy può simulare condizioni poco pratiche da riprodurre con simulazioni, ad esempio errori casuali in fase di caricamento, limitazione graduale o problemi di rete intermittenti.

Una strategia di test complementare

L'approccio più efficace combina entrambi i metodi di test:

• Utilizzare test unitari per la logica. Scrivere unit test per verificare la logica di business, le trasformazioni dei dati e i percorsi del codice di gestione degli errori specifici.
• Usare Dev Proxy per la resilienza. Usare Dev Proxy per verificare che l'applicazione gestisca correttamente le condizioni api reali, ovvero limitazione, errori e risposte lente.
• Usare entrambi in CI/CD. Eseguire test unitari per un feedback rapido su ogni commit. Usare Dev Proxy nei test di integrazione per rilevare i problemi di resilienza prima della distribuzione.

Gli unit test indicano se il codice è corretto. Dev Proxy indica se l'applicazione è resiliente. Sono necessari entrambi.

Passaggi successivi

Che cos'è il chaos testing?

• Metti alla prova la mia app con errori casuali — 5 minuti
• Usa Dev Proxy in CI/CD — esegui sia i test unitari che Dev Proxy nella pipeline