Unit test utility classes

Question

Unit test utility classes

#1 da (16 voti)
#2 da (5 voti)

5

Tutti noi abbiamo alcune classi di utilità, che contengono solo metodi statici, per l'utilizzo da fonti diverse. Ora, ci possono essere due approcci che possono essere presi per testare questo pezzo di codice.

Metodo 1:

Avere test di unità separati per classi di utilità. Ovunque vengano chiamati, prendi in giro le loro interazioni usando un framework di test che ne è provvisto, come PowerMock. Questo tratta essenzialmente la classe di utilità come componente separato del sistema, che deve essere testato e gestito individualmente.

Approccio 2:

Non scrivere test unitari per classi di utilità. Tuttavia, i test scritti per le altre classi principali che interagiscono con questa classe di utilità, consentono l'interazione, il che garantisce intrinsecamente che il codice scritto in questa classe di utilità sia correttamente testato per diversi casi di utilizzo. Se qualcosa si rompe, i test per gli altri componenti dovrebbero essere in grado di catturarlo.

Per favore condividi le tue opinioni su quale approccio è preferibile o se c'è qualche altro modo in cui le persone si comportano in questo modo.

testing unit-testing static-methods utilities

posta Ulrich 16.12.2016 - 13:24

fonte

2 risposte

16

A mio parere è ridicolo prendere in giro una dipendenza da un metodo di utilità statico per cose come la divisione delle stringhe.

Sì, se il metodo splitter è sbagliato potrebbe causare errori spuri nei test per i metodi che non riguardano la divisione delle stringhe. Ma non è questo il punto di una suite di test. La suite di test deve avere successo al 100%, punto. Se non lo fa, puoi correggere ciò che è rotto e ripetere fino a quando non riesce al 100%. Se la classe di utility della stringa viene interrotta, dovrebbe immediatamente causare un errore in un test che è sulla funzionalità della stringa. Risolvi quella funzionalità e poi tutti gli errori scompaiono, così non dovrai mai nemmeno esaminare i casi di test che falliscono spurie.

In altre parole, SÌ, scrivi test per i metodi di utilità. NO, non cercare di separarli da altri test. Supponiamo semplicemente che le semplici funzioni di utilità funzionino correttamente, come verificato dai propri test. Fare qualcosa di più è uno sforzo maggiore senza alcun guadagno.

risposta data 16.12.2016 - 14:15

fonte

Leggi altre domande sui tag testing unit-testing static-methods utilities

Che cosa ha fatto bene il tuo college e cosa potrebbero migliorare? [chiuso] In che modo Java migliora il C ++ nell'area della portabilità?

score 5 · Accepted Answer

Penso che ci sia un grosso fraintendimento sulle classi di "utilità" là fuori. Solo perché rendi una classe 'statica' non diventa una classe di utilità. Se la tua classe di utilità statica ha dipendenze (che possono manifestarsi in altre classi statiche di "utilità"), introduce effetti collaterali o il suo comportamento non può essere completamente controllato dai suoi input non è una classe di utilità.

Le vere classi di utilità non devono essere prese in giro perché il loro output è sempre deterministico a seconda dei loro input.

Il test delle unità consiste nell'istanziare una piccola parte della tua applicazione (una unità) in isolamento in modo da poter (potenzialmente) testare tutti i percorsi di codice all'interno di quell'unità. Le dipendenze derisorie ottengono questo isolamento. Se una classe di utilità interrompe l'isolamento, di nuovo non è una classe di utilità perché una classe di utilità dovrebbe essere isolata per definizione.

Quindi in un'applicazione non si dovrebbe mai voler o dover prendere in giro classi di utilità. Le classi che ritieni debbano essere prese in giro devono essere trasformate in classi istantanee di prima classe e devono essere passate nell'unità come dipendenza (vedi Iniezione delle dipendenze ). Queste dipendenze possono essere facilmente derise in modo che l'unità possa essere testata isolatamente.