Unit Testing method con più passaggi

0

Ho un metodo di convalida come questo

def validate(a, b, c, d, e, f): Boolean = {
  val rs1 = check1(a, b)
  val rs2 = check2(c, d)
  val rs3 = check3(e, f)

  rs1 && rs2 && rs3
}

Ho test per tutti i metodi più piccoli check1 , check2 e check3 e voglio testare anche il metodo big validate . Ma per testarlo, immagino di dover scrivere test per tutti i casi come:

  • tutti e 3 i controlli hanno esito positivo
  • check1 fallisce
  • check2 fallisce
  • ...

per non parlare dovrò fornire set di parametri adatti (a, b, ...).

Quindi qual è la procedura migliore per questa situazione o dovrei semplicemente saltare il test del metodo validate ?

    
posta Minh Thai 05.06.2018 - 09:26
fonte

3 risposte

0

Verifica le cose che potrebbero andare storte. Quindi, forse, scrivere test per questo metodo non avrebbe molto valore. È un codice molto semplice e improbabile che sia errato. La fonte più probabile di errori è che si passano gli argomenti errati alle funzioni check (). Se stai utilizzando una lingua tipizzata in modo statico, il rischio è già ridotto.

Si noti che un singolo caso di test (indipendentemente dal risultato della convalida) è sufficiente per fornire un'affermazione del 100% di istruzione, ramo e percorso per questa implementazione della funzione validation () se visualizzata separatamente. Tuttavia, non fornisce la copertura completa delle condizioni. Quindi scrivere almeno un caso può essere desiderabile. Forse aggiungere un secondo test case sarebbe positivo, in modo da avere un risultato positivo e uno fallito.

Oltre a ciò, il test per la copertura delle condizioni al 100% richiede sempre più sforzi per ridurre il valore. A meno che la correttezza del metodo sia estremamente importante (ad esempio un guasto potrebbe causare danni permanenti agli utenti e / o sarebbe molto costoso), ciò non sembra importante. Per testare questo metodo in modo completo, potrebbe essere opportuno riscrivere i test delle funzioni checkX() come test della funzione validate() . Ciò può comportare uno sforzo minore rispetto alla scrittura di 3 + 1 test aggiuntivi in cui si dispone di un test in cui tutti i controlli hanno esito positivo e di un test per controllo in caso di esito negativo. Inoltre, alcune persone non amano le tecniche white-box come creare casi di test per raggiungere un obiettivo di copertura invece di utilizzare i casi di test per esprimere i requisiti.

    
risposta data 05.06.2018 - 10:02
fonte
1

I have tests for all of the smaller methods check1, check2, and check3...

Questa è la causa dei tuoi attuali problemi. check1 etc sono dettagli di implementazione di validate , quindi dovrebbero essere testati solo tramite test validate . Quindi modifica i test esistenti per utilizzare validate . Questo ti dà " set di parametri appropriati (a, b, ...) ".

Tutto quello che resta da fare è testare che si convalida solo quando passano tutti i controlli.

    
risposta data 05.06.2018 - 10:59
fonte
-2

Penso che questo metodo Validate() stia potenzialmente violando il Principio di Responsabilità Unica. Secondo l'SRP, "Una classe dovrebbe avere una ragione per cambiare". Qui abbiamo tre motivi per cambiare. Quindi, stiamo violando SRP. Penso che questo sia il tuo problema principale qui.

Per rifattorici, estraperei check1() check2() e check3() nelle loro classi, li collaudo separatamente, quindi li inserisco nella classe principale del validatore. Dopo averlo fatto, ridicherei Check1Validator , Check2Validator e Check3Validator . L'unica cosa da verificare ora sarebbe l'input non valido di validate() e la condizione rs1 && rs2 && rs3.

    
risposta data 05.06.2018 - 19:18
fonte

Leggi altre domande sui tag