unit testing - karma - Linee guida per il test delle unità




unit test c# (5)

È una bella domanda Abbiamo sviluppato il nostro organico, e sospetto che il modo migliore sia proprio quello. C'è un po '"Dipende ..." lì dentro.

Abbiamo messo i test nello stesso progetto, in un sotto-spazio chiamato "UnitTes"

Le nostre classi di test rispecchiano la classe logica, al fine di semplificare la traccia di dove sono i test in relazione a ciò che stanno testando

Le classi sono denominate come la classe logica che stanno testando, i metodi sono nominati per lo scenario che stanno testando.

Scriviamo solo test per i metodi pubblico e interno (i test sono nello stesso progetto) e puntiamo a una copertura del 95% della classe.

Preferisco non distinguere tra "unità" e "intergazione". Trascorrerai molto tempo a cercare di capire quale è ... quello che! Un test è un test.

Il 100% è troppo difficile da ottenere tutto il tempo. Puntiamo al 95%. Ci sono anche rendimenti decrescenti su quanto tempo ci vorrà per ottenere l'ultimo 5% e ciò che effettivamente prenderà.

Questo siamo noi e ciò che si adatta all'ambiente e al ritmo. La tua forza può variare. Pensa al tuo ambiente e alle personalità coinvolte.

Non vedo l'ora di vedere cosa hanno da dire gli altri su questo!

Qualcuno sa dove trovare le linee guida e le raccomandazioni sui test unitari? Mi piacerebbe avere qualcosa che indirizzi i seguenti tipi di argomenti (per esempio):

  • I test dovrebbero essere nello stesso progetto della logica applicativa?
  • Devo fare in modo che le classi di test specchino le mie classi logiche o dovrei avere solo tante classi di test che ritengo debbano avere?
  • Come dovrei nominare le mie classi, metodi e progetti di test (se vanno in progetti diversi)
  • Dovrebbero essere testati metodi privati, protetti e interni o solo quelli che sono pubblicamente accessibili?
  • I test di unità e integrazione dovrebbero essere separati?
  • C'è una buona ragione per non avere una copertura di prova del 100%?

Cosa non sto chiedendo di ciò che dovrei essere?

Una risorsa online sarebbe la migliore.


In ordine:

  • No, di solito è meglio includerli in un progetto separato; a meno che non si voglia essere in grado di eseguire la diagnostica in fase di esecuzione.
  • L'ideale è la copertura del codice al 100%, che significa ogni linea di codice in ogni routine in ogni classe.
  • Vado con ClassnameTest, ClassnameTest.MethodNameTestnumber
  • Qualunque cosa.
  • Direi di sì, poiché i test di integrazione non devono essere eseguiti se i test unitari falliscono.
  • Le proprietà semplici che si limitano a impostare e ottenere un campo non devono essere testate.

Rispetto alla tua ultima domanda, secondo la mia esperienza, la "buona" ragione per non insistere sulla copertura del 100% dei test è che ci vuole uno sforzo sproporzionato per ottenere gli ultimi punti percentuali, in particolare in basi di codice più grandi. In quanto tale, si tratta di decidere se valga o meno il tuo tempo una volta raggiunto quel punto di rendimenti decrescenti.



Consiglierei il libro di Kent Beck su TDD.

Inoltre, devi andare sul sito di Martin Fowler . Ha molte buone informazioni anche sui test.

Siamo piuttosto grandi su TDD quindi risponderò alle domande in questa luce.

I test dovrebbero essere nello stesso progetto della logica applicativa?

In genere manteniamo i nostri test nella stessa soluzione, ma suddividiamo i test in progetti / DLL separati che rispecchiano i progetti / le DLL che stanno testando, ma mantengono lo spazio dei nomi con i test in uno spazio secondario. Esempio: test comuni / comuni

Devo fare in modo che le classi di test specchino le mie classi logiche o dovrei avere solo tante classi di test che ritengo debbano avere?

Sì, i test dovrebbero essere creati prima che vengano create tutte le classi e, per definizione, si dovrebbe testare una singola unità separatamente. Pertanto dovresti avere una classe di test per ogni classe nella tua soluzione.

Come dovrei nominare le mie classi, metodi e progetti di test (se vanno in progetti diversi)

Mi piace sottolineare che il comportamento è quello che viene testato, quindi in genere assegno alle classi di test dopo il SUT. Ad esempio, se avessi una classe utente, chiamerei la classe di test in questo modo:

public class UserBehavior

I metodi dovrebbero essere denominati per descrivere il comportamento che ci si aspetta.

public void ShouldBeAbleToSetUserFirstName()

I progetti possono essere nominati come vuoi, ma di solito vuoi che sia abbastanza chiaro quale progetto sta testando. Vedi la risposta precedente sull'organizzazione del progetto.

Dovrebbero essere testati metodi privati, protetti e interni o solo quelli che sono accessibili pubblicamente?

Ancora una volta si desidera che i test asseriscano il comportamento previsto come se si fosse un consumatore di terze parti degli oggetti sottoposti a test. Se si testano i dettagli di implementazione interna, i test saranno fragili. Vuoi che il tuo test ti dia la libertà di refactoring senza preoccuparti di rompere le funzionalità esistenti. Se il tuo test è a conoscenza dei dettagli di implementazione, dovrai modificare i test se tali dettagli cambiano.

I test di unità e integrazione dovrebbero essere separati?

Sì, i test unitari devono essere isolati dai test di accettazione e integrazione. La separazione delle preoccupazioni si applica anche ai test.

C'è una buona ragione per non avere una copertura di prova del 100%?

Non avrei mai smesso di appendere la cosa al 100% di copertura del codice. La copertura del codice al 100% tende a implicare un certo livello di qualità nei test, ma questo è un mito. Puoi avere test terribili e ottenere ancora una copertura del 100%. Vorrei invece fare affidamento su una buona mentalità di Test First. Se scrivi sempre un test prima di scrivere una riga di codice, assicurerai una copertura del 100%, quindi diventa un punto controverso.

In generale, se ti concentri sulla descrizione dell'intero ambito comportamentale della classe, non avrai nulla di cui preoccuparti. Se rendi una copertura del codice una metrica, i programmatori pigri faranno semplicemente quel che basta per raggiungere quel marchio e avrai ancora dei test scadenti. Invece fare molto affidamento sulle revisioni tra pari in cui vengono esaminati anche i test.







tdd