La risposta breve è sì.
Ci sono molti più casi ma, poiché stai prendendo in considerazione il cortocircuito, devi solo considerare un caso in cui A è Falso e solo un caso in cui A è Vero e B è Vero e non devi preoccuparti controllare C. L'unica volta che è necessario controllare tutti e tre i valori è se A è Vero e B è Falso.
EDIT ** Con la nuova espressione (A & E & & (B || C || D)) Con questa nuova espressione e tenendo ancora conto del breve comportamento, ti preoccuperai solo delle istanze in cui sia A sia vero che E è vero. Da lì, hai solo bisogno di testare B || C || D in questo ordine finché non trovi un valore vero. Quindi queste istanze:
T--
FT-
FFT
Quindi D verrà controllato solo se B e C sono False. C verrà controllato solo in B è falso. Se B è vero, non è necessario controllare ulteriormente.
Supponendo che ciascuno dei valori sia indipendente dall'altro (che il valore di B non dipenda dal valore A), allora il numero minimo di casi di test è (i valori veri sono cap, false sono in minuscolo):
La difficoltà con l'implementazione del numero minimo è che se il codice cambia (metodo di estrazione refactoring sul condizionale) ma la logica di business non lo fa, potrebbe mancare un risultato errato.
Nel caso generale dovrai controllare ogni combinazione. Il codice sotto if può dipendere da qualsiasi numero di variabili, il cui stato si riflette nei test A-E . Cosa succede se la variabile x viene impostata ogni volta che la condizione C è vera, ma il percorso di esecuzione attraverso la condizione D non lo imposta? Cosa succede se chiamare D ha effetti collaterali che influiscono sul blocco condizionale?
In pratica, questo tipo di codice può incapsulare piccoli punti in comune tra diversi percorsi di esecuzione ed è difficile ottenere tutti i percorsi per impostare correttamente lo stato. Quindi errori di questo tipo sono che potrebbero accadere.
Leggi altre domande sui tag testing code-reviews conditions