Copertura dei test unitari

Sono d'accordo con Peter. Sembra che tu abbia la sensazione istintiva di qualcosa che non ritieni valga la pena di testare, ma sai da un libro di testo che più prove e meglio è.

In primo luogo, la copertura del test del 100% è impossibile e non vale lo sforzo nel tentativo di raggiungere. 85% o oltre, e stai andando bene.

Per quanto riguarda il tuo framework ORM, ancora una volta, tocca a te. Permetterete agli sviluppatori di estendere / modificare il comportamento di qualsiasi cosa generata, se così fosse, potrebbe essere utile per avvolgerli in alcuni test generati. Se si tratta di un libro chiuso, allora qual è il punto?

Test generati per colpire i proc nel database, dove potrebbero essere modificati dagli sviluppatori / DBA (e di solito lo sono), di nuovo, potrebbe essere bello avere un test generato per questo se non è troppo difficile da fare.

È sempre un compromesso - ne vale la pena? Questo di solito si presenta anche quando le persone pensano di scrivere test su classi di entità con solo get / setters su di loro ...

Nella stesura dei test unitari, dovresti sempre usare il tuo giudizio su cosa e quanto testare. Nessuna regola di un libro di testo può adattarsi ad ogni specifico progetto e situazione. Abbiamo risorse limitate, che dovremmo usare con parsimonia per ottenere il massimo beneficio per il tempo e l'impegno indicati. Ci sono sempre parti di codice che non possono essere ragionevolmente testate, ma ci possono essere modi migliori per testarli, come test di integrazione / sistema / funzionali.

Anche nelle classi che esegui il test unitario, non è ragionevole aspettarsi una copertura del 100% . C'è sempre un codice di gestione degli errori / delle eccezioni, che è difficile da testare e non offre molti vantaggi (se non del tutto).

Quindi per ogni classe / metodo tu (o preferibilmente l'intero team di sviluppo) dovresti chiediti se sei abbastanza sicuro che questo codice funzioni . In altre parole, può essere spedito oggi? In caso contrario, trovare un modo per garantire la sua qualità, sia esso unità o altri tipi di test.

La copertura del test non dice nulla. Dice che test la classe, ma non dice nulla su tutte le permutazioni (diversi scenari) che puoi testare la classe.

Modifica

Ad esempio hai x campi con y stato diverso ciascuno in un oggetto. Questi stati generano diversi scenari di business (regole). IMO un test di unità completo di significato sulla classe è uno che copre tutte le possibili permutazioni di questi stati. Uno scenario più complesso è quando questo oggetto interagisce con un altro oggetto. In tal caso gli stati di permutazione per la tua classe devono anche essere combinati con altre classi. Uno scenario realistico è quello di restringere a tutti gli scenari possibili, in tal caso si prendono solo le permutazioni possibili nel test.

Ognuno ha il proprio livello di comfort (anche se alcuni sono un po 'troppo comodi), ma per quanto mi riguarda, cerco di avvicinarmi il più possibile alla copertura della logica aziendale al 100%. Scrivo principalmente software finanziario, quindi questo potrebbe essere per cose come controllare che gli elementi pubblicitari si sommano in un totale, ecc.

Inoltre, tieni presente che la copertura del test del 100% non è necessaria, poiché onestamente non miriamo al 100% di software privo di errori . Prima che la gente afferri i forconi, intendo dire che ci sforziamo di fermare i bug all'interno di un ambito accettabile. Qualcuno potrebbe provare a eseguire la mia app finanziaria interna attraverso la macchina virtuale del proprio ufficio che si trova su un sistema operativo Solaris. Beh, succede proprio che corriamo sullo stack Microsoft, quindi nonostante il fatto che la mia app "dovrebbe" essere eseguita su Solaris VM, mi potrebbe importare di meno che non funzioni, anche se è totalmente colpa delle mie app. Quel caso sarebbe al di fuori della portata di errori inaccettabili, quindi non testerò per questo. Ciò che deve essere testato è anche un sottoinsieme di possibilità nella lista di errori non accettabili. Più che semplicemente essere inaccettabili, devono essere in qualche modo suscettibili di verificarsi. Non c'è bisogno di testare che il compilatore si romperà e leggerà male il tuo codice o qualcosa del genere.

Il codice che viene spedito, deve essere testato, o spedirai bug. Tuttavia, Test unitari sono solo uno strumento per testare il codice.

Ho lavorato a progetti regolarmente spediti privi di bug con una copertura del codice di test unitario di circa il 20%, che utilizzava anche script di test manuali e tester intelligenti. Al contrario, attualmente sto lavorando a un progetto che ha una copertura del codice intorno all'85%, che si basa molto più pesante sui test unitari per ottenere un risultato simile.