Linee guida per unità di migliori test

Question

Jimmy Bogard, ha scritto un articolo: Getting value out of your unit tests, dove tiene quattro regole:

• nomi di prova deve descrivere il che cosa e il perché, dal punto di vista dell'utente
• I test sono codice di troppo, dare loro un po 'di amore
• non si depositano su un modello di apparecchio/stile organizzativo
• One Setup, Eseguire e Verificare per test

Secondo lei queste linee guida sono completi? Quali sono le tue linee guida per i test unitari? Si prega di evitare idiomi linguistici specifici, cercare di mantenere le risposte indipendenti dalla lingua.

Answer 1

C'è un intero, 850 pagine del libro chiamato xUnit Test Patterns che si occupano di questo argomento, quindi non è qualcosa che può essere facilmente bollito alcune regole rigide (anche se le regole che menzioni sono buone).

Un libro più digeribile che copre anche questo argomento è The Art of Unit Testing.

Se posso aggiungere le regole che trovo più importante, sarebbero:

• Sviluppo Usa Test-Driven. È la strada di gran lunga più efficace verso buoni test di unità. Cercare di adattare i test di unità al codice esistente tende a essere al massimo difficile.
• Semplicità: idealmente, un test di unità deve essere inferiore a 10 righe di codice. Se cresce a più di 20 righe di codice, dovresti prendere seriamente in considerazione il refactoring del codice di test o dell'API che stai testando.
• Resta veloce. Le suite di test unitarie devono essere eseguite molto frequentemente, quindi mirano a mantenere l'intera suite sotto i 10 s. Ciò può facilmente significare mantenere ogni test sotto i 10 ms.

Answer 2

Scrivere i test di unità è semplice, sta scrivendo un codice testabile dall'unità che è difficile.

Answer 3

• Rompere il codice di prova regolarmente per vedere l'efficacia del gruppo di test

Answer 4

The Way of Testivus

• Se si scrive il codice, scrivere dei test.
• Non rimanere bloccato sul dogma dell'unità di test.
• Embrace unit test karma.
• Pensa al codice e prova come uno.
• Il test è più importante dell'unità.
• Il momento migliore per testare è quando il codice è fresco.
• I test non vanno perduti.
• Un test imperfetto oggi è meglio di un test perfetto un giorno.
• Un test brutto è meglio di nessun test.
• A volte il test giustifica i mezzi.
• Solo gli sciocchi non usano strumenti.
• I buoni test falliscono.

Answer 5

Per molte altre buone idee scrivere test di unità, search stackoverflow.com.

Answer 6

Dai un'occhiata alla copertura del codice dei tuoi test e cerca di renderlo ragionevolmente completo (per i casi di errore userei un po 'di discrezione se testarli o meno).