Test di unità e realtà [chiuso]

Question

Test di unità e realtà [chiuso]

#1 da (10 voti)
#2 da (3 voti)

2

In realtà sto studiando i test delle unità, sto leggendo alcuni articoli su Internet e sto cercando di capire come funziona esattamente, ma in realtà non è molto chiaro per me.

Che cosa devo testare?

Ho visto che è una buona cosa creare interfacce e rendere le nostre classi testabili implementare questa interfaccia (permettendo di implementarla nelle nostre classi di test) ma quali sono esattamente le classi che dovrei testare?

Ad esempio, ammettendo che ho una struttura di progetto come questa:

Presentation Layer (MVC)
Livello aziendale (servizio / archivi)
DB Layer (Mongo, Mysql ecc.)

Dovrei testare solo servizi e repository? Devo creare un'interfaccia per tutte le mie classi, anche se ne ho solo un'implementazione (due con il test)?

Che cosa restituisce davvero il mio test?

Ho letto un articolo in cui l'autore spiegava come testare un accesso DB usando i mock:

Esiste una classe "S" che è un servizio aziendale che implementa un'interfaccia "I", che gestisce i dati prelevati dal db per fornire oggetti di business
Esiste una classe "C" che è un controller e ha un metodo renderView, che invia alla vista una matrice degli oggetti di business dati dal servizio "S".

1 / Nel primo test, verifica il valore restituito da "S" su getBusinessObject utilizzando solo una raccolta di String. Quindi verifica solo se ha dati nella raccolta (null, il contenuto dopo aver aggiunto un elemento ecc ...)

2 / Nel secondo test, prende in giro il servizio "S" per usarlo per testare il renderView e verifica solo se ottiene 2 risultati quando il metodo dell'oggetto mock restituisce 2 oggetti.

La mia domanda è, come possiamo dire che il test è una rappresentazione dello stato reale del nostro programma?

Voglio dire, è possibile che dobbiamo fare un lavoro difficile in un servizio, con condizioni, iterazioni ecc ...

Non capisco davvero l'impatto del fare test di unità se prendiamo in giro una classe che

return "a string";

confronto con una classe che trasforma drasticamente una stringa nel metodo.

Forse non ho capito l'obiettivo del test unitario in effetti.

unit-testing java

posta mfrachet 19.12.2014 - 10:48

fonte

2 risposte

3

I test unitari sono essenzialmente test di un singolo componente. Con forse alcuni oggetti finti per simulare alcune interfacce utilizzate dal modulo.

Stai testando che per un determinato input ricevi l'output atteso. Se esegui test coinvolge altri componenti o servizi di moduli che non possono essere sottoposti a simulazione, allora non è più un test unitario.

In quanto tali sono molto utili. Puoi testare condizioni marginali e valori estremi che sono improbabili ma che potrebbero apparire in dati reali.

Tuttavia il test unitario è solo l'inizio. Il modulo deve essere testato con gli altri moduli nel sistema e, con qualsiasi altro sistema con cui interagisce.

Inoltre, è necessario eseguire test realistici con utenti reali, un programma può essere considerato "funzionante" solo se l'utente ritiene che funzioni.

risposta data 19.12.2014 - 13:21

fonte

Leggi altre domande sui tag unit-testing java

Quanto è corretto questo piccolo design di gioco senza rimuovere il suo schema di progettazione? A quali applicazioni per programmi auto-adattivi riesci a pensare? [chiuso]

score 10 · Accepted Answer

Ho avuto appaltatori che hanno lasciato dopo aver creato un livello database con una serie di test unitari che sono passati, ma in realtà non ha salvato nulla nel database, quindi tutto è andato perso se si è riavviato il sistema.

Quindi prova le parti del tuo sistema che vuoi lavorare scrivendo dei test che confrontano il comportamento atteso con il comportamento reale.

Se quelle parti sono abbastanza piccole per essere testate senza molte impalcature e configurazioni, allora quei test sono unit test. Se richiedono più parti per lavorare in concerto, allora sono test di integrazione.

Se ritieni che preferiresti essere codificato piuttosto che aspettare l'esecuzione di lunghi test di integrazione, quindi ridimensionare il sistema in parti più piccole che possono essere testate usando i test unitari.

Spesso ciò comporta la creazione di interfacce e mock / stub in modo tale che i livelli aziendali e dell'interfaccia utente possano essere testati rapidamente senza un vero database. Il livello dell'interfaccia utente probabilmente non interessa se la cosa visualizzata è "una stringa" o dati reali. Allo stesso modo, al livello DB potrebbe non importare se gli viene chiesto di memorizzare dati reali o 'una stringa' †. Il livello aziendale che fa qualcosa ai dati potrebbe essere utile.

La chiave qui è che i mock dovrebbero restituire qualcosa che eserciterà la funzionalità sotto test, ma non saranno più complicati di quanto sia necessario per farlo.

Ti ritroverai con più test unitari e meno test di integrazione e un sistema meglio fattorizzato, ma hai ancora bisogno dei test di integrazione per verificare che effettivamente soddisfi le specifiche generali.

_{† in realtà, la maggior parte dei miei progetti memorizza quantità di dati di serie temporali, quindi la natura dei dati reali determina la struttura del database, quindi in genere eseguo il test utilizzando pochi mesi di dati reali, non inventati.}