Test dell'app di front-end che colpisce un servizio REST

Question

Test dell'app di front-end che colpisce un servizio REST

#1 da (1 voti)
#2 da (0 voti)
#3 da (0 voti)

3

Un sacco di domande sui test qui ... E ne ho un altro. Perdonami, ma voglio assicurarmi di farlo bene.

Supponiamo di avere un'applicazione front-end, che si tratti di un'app mobile o di un sito web a pagina singola o qualsiasi altra cosa. Questa app raggiunge un servizio REST, anch'esso sviluppato. Il servizio recupera i dati da API REST di terze parti, elabora questi dati e restituisce i risultati all'applicazione.

Il mio servizio è ben testato e sviluppato in modo esagonale, con test completi di black-box unit (dati predefiniti) e pochi test di integrazione (che colpiscono i servizi di terze parti) per vedere che gli adattatori funzionano correttamente con le porte ( vedi qui ).

Il mio front end è anche ben collaudato con test unitari e dati falsi (in realtà non ha colpito il servizio nei test). Penso che sarebbe bello se fosse testato insieme al servizio che sviluppo. Le poche cose di cui non sono sicuro:

Devo utilizzare i dati predefiniti durante il test del mio servizio o devo utilizzare le API di terze parti nei test?
Dovrebbero essere test automatici completi (a patto che tutte le funzionalità siano già testate con dati predefiniti sul front-end, e anche il servizio sia davvero ben testato, quindi molti di questi test verrebbero testati su ciò che è già stato testato) o dovrebbe essere solo alcuni test manuali, come colpire alcuni pulsanti e vedere se i dati arrivano? Qui penso principalmente al rapporto costi / benefici.
Esistono framework per scrivere test automatizzati di questo tipo?

Sono sicuro che molti di voi erano in una situazione simile. Quindi sarebbe bello avere qualche consiglio. Se è possibile collegare un white paper o una conferenza sull'argomento, sarebbe ancora meglio. Grazie in anticipo per eventuali suggerimenti.

testing unit-testing integration-tests rest

posta Daniel Gruszczyk 09.03.2015 - 16:12

fonte

3 risposte

Leggi altre domande sui tag testing unit-testing integration-tests rest

Dove si inserisce il codice del dispositivo di prova? Utilizzare più dispatch dinamico potrebbe ridurre i tempi di compilazione?

score 1 · Answer 1

Se non possiedi le API REST, la tua responsabilità termina con loro

Sono necessari test che controllano se la tua applicazione chiama correttamente l'API sotto il tuo controllo. Pertanto, utilizzare l'applicazione effettiva con il servizio effettivo (quello che si controlla) ma chiamando i servizi mocked (quelli che non si controllano).

...

Utilizza i dati predefiniti per i servizi che non controlli, reindirizza i dati al servizio effettivo e utilizzali dall'applicazione.
Questo dovrebbe essere un test molto ampio per verificare semplicemente se le chiamate dall'applicazione passano al servizio. A questo punto dovresti già aver testato a fondo la tua applicazione con le risposte che il tuo servizio potrebbe restituire e dovresti testare accuratamente il tuo servizio con le risposte che i servizi che non puoi controllare potrebbero restituire. Tutto questo preferibilmente automatizzato. A seconda della quantità di rilasci che fai, potrebbe essere più facile testarlo manualmente prima del rilascio.
Dipende dalla tecnologia utilizzata, che potrebbe non rendere questo il miglior sito web per quella domanda.

score 0 · Answer 2

Sì, si dovrebbe sempre testare il sistema con tutta l'architettura del mondo reale, se possibile, alcuni problemi possono verificarsi solo nei test di sistema / dati reali (memoria esaurita / connessione bloccata / stabilità dell'ambiente).
Se la logica aziendale e la comunicazione dei dati hanno dimostrato di funzionare alla grande, la prossima cosa su cui concentrarsi sarà lo stress test per il servizio: per quanto riguarda i server, quante richieste possono essere gestite in un dato momento ? in che modo la larghezza di banda / CPU / thread / memoria del server di applicazioni Web distribuito può sopportare?
Per il framework di stress test, abbiamo provato WAPT e dovrebbe essere sufficiente per il caso di stress test generale.

score 0 · Answer 3

Secondo me, ci sono due scenari distinti che stai testando.

1) Verifica che la tua applicazione stia invocando correttamente le API esterne.

L'obiettivo di questi test è isolare il codice dell'applicazione e accertarsi che invochi e risponda correttamente alle API esterne. Di conseguenza, questi dovrebbero essere fatti con servizi di simulazione e dati per eliminare il rumore irrilevante dal test.

2) Verifica che le API esterne siano disponibili e rispondano come previsto.

L'obiettivo è garantire che l'applicazione disponga di tutte le risorse necessarie per funzionare correttamente. Non è un test di unità, dal momento che non stai esercitando alcun pezzo di codice. Questo è un monitor di integrità del sistema. Generalmente è di valore molto basso eseguire un singolo test rispetto a una dipendenza esterna in fase di compilazione, si desidera che questi controlli continuino a intervalli regolari e generino avvisi appropriati quando falliscono. La soluzione ideale è un'applicazione separata che si affiancherà all'applicazione che monitorerà tutte le risorse esterne da cui dipende l'applicazione. Stabilire un corretto monitoraggio e avviso su queste dipendenze esterne attraverso un monitoraggio dello stato del sistema è essenziale negli scenari di alta disponibilità al fine di rispondere nel modo più rapido ed efficiente possibile per mitigare qualsiasi interruzione del servizio.