Copertura del codice o Test di brevità?

Question

Copertura del codice o Test di brevità?

#1 da (7 voti)

4

Ultimamente sto scrivendo molti test unitari e sono diventato un po 'ossessionato dalla copertura del codice. Tuttavia, sto lottando per giustificare la copertura del 100% del codice, quando così tanti test sarebbero ridondanti e ingigantire davvero i miei test unitari.

Ad esempio, immagina un endpoint cliente di un'API. L'utente pubblica un ID cliente, la sua posizione e alcuni dati. Sembra /api/customers/:locationId/:customerId .

Ecco un esempio di snippet di copertura del codice proveniente da Instanbul, sto usando Node.js:

La prima mancanza, non riuscendo ad aggiornare il cliente, è qualcosa che dovrebbe assolutamente essere testato. Ma gli ultimi 2, non riuscendo a trovare la posizione e il cliente, sono presenti su quasi ogni endpoint. Devo davvero passare in una posizione errata, e quindi un cliente sbagliato, per ognuno degli endpoint (creare, aggiornare, cancellare, ecc.)? O dovrei semplicemente vivere con chi non è coperto?

testing unit-testing test-coverage

posta user1767270 12.08.2015 - 20:53

fonte

1 risposta

Leggi altre domande sui tag testing unit-testing test-coverage

Modelli di progettazione quando la classe ha bisogno di consapevolezza esterna Stima dei punti di mischia per team non interfunzionali

score 7 · Accepted Answer

La copertura del test è buona. Il 100% di copertura del test è assolutamente raggiungibile senza una folle quantità di sforzo ^[1], tranne ovviamente per quelle affermazioni che possono mai succedere, ma lascia che siano comunque affermazioni.

^{[1]: ipotizzando codice ragionevolmente verificabile}

Soprattutto quando si parla di gestori di errori, questi hanno devono essere coperti dai test. Il "percorso felice" sarà implicitamente testato dal normale utilizzo. Ma se le cose vanno male, vuoi assicurarti che le cose vadano per la tua strada. Sarebbe un peccato se un piccolo stupido errore significherebbe che il codice di gestione degli errori produrrebbe di per sé un errore. Errori corretti rendono inoltre più facile per gli utenti dell'API capire perché il loro codice non funziona: sono una caratteristica importante del tuo codice.

Nel contesto di un'API web, la verifica di tutti gli input può essere di fondamentale importanza per la sicurezza: la programmazione difensiva dovrebbe essere la regola, non una caratteristica accidentale. Ovviamente, questa convalida deve essere testata!

Un altro consiglio: nel tuo esempio, il tuo codice ha una quantità straordinaria di indentazione. Questo può essere un segno che la tua funzione dovrebbe essere suddivisa in più funzioni più piccole che possono essere testate separatamente. Anche le chiusure sono difficili da testare; l'utilizzo di funzioni con nome aumenta la testabilità. Inoltre, lunghe cascate del modulo

if (a) {
  if (b) {
    if (c) {
      happy_path;
    } else {
      error_c;
    }
  } else {
    error_b;
  }
} else {
  error_a;
}

può essere riscritto come

if (!a) {
  error_a;
}

if (!b) {
  error_b;
}

if (!c) {
  error_c;
}

happy_path

Queste "guardie" rendono il codice più lineare e nella mia esperienza sia più facile da capire e più facile da testare.