Questo test chiamerebbe ripetutamente un servizio web per circa un minuto per confermare che un particolare codice di risposta è stato restituito, notificandoci che il nostro limite di velocità è stato raggiunto. Non solo è un test molto lento, non conferma molto nulla e spreca risorse.
Sento che questo è come confermare che sbuffare una bottiglia di vodka ucciderà un umano. Abbiamo davvero bisogno di un test per questo?
Parte del motivo per cui testiamo è verificare le nostre supposizioni secondo cui il codice funziona come progettato. Se non ti importa dei risultati che questo test sta restituendo, non è utile e dovresti buttarlo via.
Al contrario, se fai ti preoccupi, ei risultati del test ti aiutano a sviluppare il miglior software possibile, mantienilo.
Il punto di test è di aiutare a fornire codice di alta qualità. Se una particolare attività di test ti avvicina a quell'obiettivo, fallo. Se non lo fa, non farlo.
Se non aumenta la tua sicurezza in alcuni aspetti del sistema, rilasciala. (Inoltre, +1 per "confermare che sbuffare una bottiglia di vodka ucciderà un umano.")
In questa situazione (presupponendo un servizio web di terze parti), non scrivo il test che effettivamente ottiene il servizio per restituire una risposta a velocità limitata. Invece, ho un test che verifica il comportamento previsto quando si riceve la risposta .
Salva una risposta di limitazione della velocità dal servizio e rispedisci quella risposta anziché chiamare il servizio web effettivo. Non solo il test viene eseguito molto più velocemente, ma può anche essere eseguito offline e probabilmente porterà a una migliore progettazione del codice.
Nel codice pseudo Java / Mockito-ish sembrerebbe qualcosa di simile:
// pretend we are rate limited
when(client.callService()).thenReturn(RATE_LIMITED_RESPONSE);
// call the service
response = getResponse(client);
// decision based on rate limited response is correct
assertEquals(Status.RATE_LIMITED, response.getStatus());
dove getResponse() chiama client.callService() e successivamente gestisce tutta la logica basata sul contenuto della risposta.
Se hai già un test come questo, allora il test di integrazione sta solo testando che il servizio web restituisce una risposta a velocità limitata in un formato che ti aspetti.
Il mio approccio sarebbe quello di rendere il limite di velocità configurabile al volo attraverso un meccanismo. E ora il tuo test di integrazione può testare entrambi i comportamenti abbassando sostanzialmente la velocità e superandola.
I limiti tariffali configurabili possono o non possono rivelarsi utili indipendentemente. Ma penso che sia importante essere in grado di testare con cura che le garanzie a cui si sta dipendendo sono effettivamente lì.
Leggi altre domande sui tag testing integration-tests web-services http-response