Focus dei test unitari sul codice [duplicato]

Question

Focus dei test unitari sul codice [duplicato]

#1 da (0 voti)

1

Scopro strategie di beffeggiamento dopo che è stato scritto il 50% dei test, e sono confuso su quanti test di messa a fuoco debbano avere, per esempio sul metodo di classe. So che per le dipendenze esterne dovresti prendere in giro quelle, ma se dovessimo chiamare qualche altro metodo nella stessa classe. Questo sarebbe considerato dipendenza? ... Perché vogliamo testare la correttezza solo il metodo che stiamo testando ... giusto? Ma dove finisce la messa a punto del test unitario?

Il test unitario dovrebbe testare in OOP il più piccolo blocco di codice ... e 2 test non dovrebbero essere dipendenti. Quindi se il più piccolo blocco di codice è un metodo di classe, il test unitario dovrebbe testare solo un metodo di classe. Ma se qualcuno modifica un metodo e il test per quel metodo fallisce, fallirà qualsiasi altro metodo in classe che dipende da esso. Quindi per rendere il test veramente indipendente dovrei prendere in giro il metodo dei dipendenti?

Il mio pensiero prima di scrivere il mio primo test è che il test unitario sta testando il più piccolo gruppo di codice come metodo o funzione di classe e fa asserzioni sugli effetti collaterali ... Quali sono i tuoi pensieri su questo e quali dovrebbero essere le migliori pratiche.

unit-testing

posta Uroš Jarc 05.07.2015 - 18:13

fonte

1 risposta

Leggi altre domande sui tag unit-testing

Come strutturare i dati enum per ottenere l'effetto desiderato Come valutare una connessione ricorrente in una rete neurale artificiale?

score 0 · Answer 1

Forse potresti riformulare la tua domanda a: Che cosa è esattamente un unit nei test unitari.

Penso che sia comunemente d'accordo, che, se stai facendo OOP, una classe vale per un unit . Ma non esiste una definizione formale di ciò. Potresti fare test unitari con interi sottosistemi, testando principalmente il codice collante , ma indirettamente tutte le dipendenze insieme.

C'è un bell'articolo di Martin Fowler sul "problema" di una unità .

I know that for external dependencies you should mock those but what if we call some other method in the same class

Per lo più definisci un object under test , ad esempio un customerservice . Questo servizio clienti viene chiamato da un altro oggetto. Questo comportamento attiva i test. Il customerservice effettua chiamate a customerrepository . Queste chiamate sono candidati perfetti per deridere.

Stai testando customerservice e vuoi risposte affidabili al suo comportamento. Da questo dovrebbe essere chiaro, che non ha senso, in qualche modo prendere in giro le chiamate sul tuo oggetto in prova. Se devi effettuare una chiamata a un'altra funzione dello stesso servizio, fa parte del test.

Would this considered to be dependency?

Non nel senso comune di dependencies che significa external dependencies .

But where unit test focus ends?

Dai bordi dell'unità che collaudi. Nell'esempio fornito tutti i metodi di unit chiamato customerervice .