Come errori del server di test di integrazione (http 500)

Naviga le tue risposte
2

Come nel titolo: come si verificano errori del server di test di integrazione che restituiscono 500 risposte HTTP?

Ad esempio:

  1. C'è un server con un endpoint /save che accetta file in POST e lo salva nel file system del server
  2. C'è una libreria / dipendenza X che gestisce la funzionalità di salvataggio dei file da qualche parte nell'altra parte dell'applicazione
  3. X può fallire in una serie di motivi, ma per questo esempio diciamo che si blocca perché non c'è spazio sul disco
  4. Vorremmo lanciare un HTTP 500 invece di bloccare il processo

Che cosa fai in questa situazione?

  1. Ti prendi in giro X e in effetti hai generato un errore nel test?
  2. Ometti questi tipi di test e maneggi solo gli errori da qualche parte a livello globale?
  3. Ti basta l'integrazione testare i percorsi felici e ignorare i casi di errore e testarli nei test unitari?
  4. Qualcos'altro?

E una domanda che forse risponde a tutta la mia lotta:

Verifica se ogni possibile errore restituisce un HTTP 500 qualcosa che chiameresti overengineering o è piuttosto una buona pratica?

    
posta sarneeh 26.08.2018 - 09:49
fonte

2 risposte

1

Fondamentalmente hai tre cose da testare.

  1. Il componente genera l'eccezione corretta quando non si utilizza lo spazio su disco?

    Questo può essere verificato prendendo in giro la dipendenza in un test di unità e lanciando l'errore desiderato.

  2. Il livello di hosting restituisce tutte le eccezioni all'utente come HTTP 500

    Questo può essere verificato con un test di integrazione che verifica uno scenario di errore. Probabilmente uno dei tuoi altri test che conosci apporterà determinati input.

  3. L'eccezione specifica in questione restituisce un errore HTTP 500

    Questo è più difficile da testare ma puoi ancora farlo iniettando il tuo simulatore nell'applicazione completa. Vorrei codificare il mock per restituire diverse eccezioni a seconda dell'input per consentire allo stesso mock di testare una varietà di scenari.

In pratica salterei 3 a meno che non ci fosse qualcosa di strano in proposito. Stai solo testando la tua gestione globale degli errori e non potrai mai coprire tutte le possibili eccezioni

    
risposta data 29.08.2018 - 09:58
fonte
0

Nei test di integrazione end-to-end, vorrei concentrarmi sui percorsi felici e su alcuni scenari di errore facili da attivare.

Gli scenari di errore più elaborati o difficili da attivare dovrebbero essere trattati nei test unitari e nei test dei componenti.

Nello scenario che descrivi, dovrebbe esserci un test per

  • l'app per verificare il comportamento quando il server risponde con il codice 500
  • il server per verificare che risponda con il codice 500 se c'è un errore imprevisto nella libreria X
  • libreria X per verificare che fornisca un'indicazione di errore corretta quando il file files è pieno.

Questi sono tutti test di livello unità / componente con la maggior parte delle dipendenze prese in giro o stubbate.

    
risposta data 26.08.2018 - 13:57
fonte

Leggi altre domande sui tag

Utilizzo di SPA (applicazione a pagina singola) in produzione con un file / modulo di configurazione separato Quale terminologia è associata alla manutenibilità irregolare?