Come testare un servizio REST senza essere eccessivo

Question

Come testare un servizio REST senza essere eccessivo

#1 da (2 voti)

2

Quindi ho un backend REST (in node.js o Java non importa ma l'esempio è in js).

Cerco di avere un servizio per ogni endpoint in modo che l'endpoint / utenti abbia due file:

usersRouter.js che include gli endpoint del router con codice di esempio:

router.get('/users/:username',function(req,res,next){ 
    return userService.find(username);
}

userService.js

function find(username) { //do some database stuff here }

Penso che le best practice richiedano di testare tutti i metodi della tua app con entrambe le unità testando il servizio e l'integrazione testando l'endpoint.

È davvero necessario in questo caso? Se l'endpoint chiama solo un metodo, potrei testare solo questo con tutti gli scenari disponibili.

Un lato negativo sarebbe che la funzione ha più opzioni che non sono utilizzate dall'endpoint e potrebbero essere utilizzate da un altro endpoint / funzione, ma è troppo per testare quasi la stessa cosa due volte?

tdd unit-testing integration-tests

posta arisalexis 22.09.2015 - 16:42

fonte

1 risposta

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

Consigli di architettura di design sulla relazione tra oggetti e singleton JS Progettazione dell'API HTTP C ++

score 2 · Accepted Answer

Durante il testing unitario del livello di servizio, questi test dovrebbero solo verificare la logica nel livello di servizio stesso e dovrebbero essere veloci e isolati da possibili errori che si trovano al di fuori del livello di servizio. Ciò significa che nei test unitari del livello di servizio, le dipendenze del livello di servizio che non possono essere "garantite" sono esenti da errori o che potrebbero causare un rallentamento dei test. In particolare, l'accesso al database dovrebbe essere deriso nei test delle unità, perché i database causano molti problemi nei test delle unità (in parte a causa della lentezza della connessione, e in parte perché mantengono lo stato tra i test, il che rende difficile mantenere i test indipendenti).

Nei test di integrazione dell'endpoint testare tutto il codice coinvolto quando viene utilizzato il punto finale, incluso il database.

Se c'è una piccola logica in una particolare funzione nel livello di sessione, allora potresti rinunciare al test unitario di quella funzione. Questo potrebbe essere basato su una valutazione del rischio su quanto sia grande la possibilità che qualcosa vada storto in quella funzione che non verrebbe catturata in un altro modo.