Indipendentemente dal fatto che un valore sia null potrebbe essere controllato implicitamente in questo modo:
assertThat(value).isEqualTo("something");
Oppure potrebbe essere controllato esplicitamente:
assertThat(value).isNotNull();
assertThat(value).isEqualTo("something");
Quest'ultimo rende le aspettative un po 'più chiare, ma fa esplodere il codice di test.
C'è una buona ragione per preferire il secondo approccio rispetto al primo?
Suppongo che alla fine dipenda dalle preferenze. Tecnicamente, se non si prova se un particolare valore è nullo, è necessario testarlo assumendo che non sia nullo. Il test fallirà lo stesso, ma c'è una sottile differenza che non l'hai previsto nel tuo test, quindi è un po 'come dire "C'è qualcosa di veramente sbagliato qui".
La maggior parte delle volte, null è una possibilità quando le cose vanno male, quindi controllo esplicitamente. Se testare che il risultato è nullo vale il suo test, allora faccio un intero test testandolo proprio così. Altri test che richiedono che non sia null non controllano. Alla fine tutto fallisce, ma almeno a mio modesto parere, è più chiaro cosa mi aspetto di provare in questo modo.
Dipende interamente dalla tua strategia generale e dal tuo flusso di lavoro nell'uso dei test unitari.
I sostenitori del TDD non si preoccupano molto esattamente di che cosa succede quando un test di un'unità fallisce. Una NullPointerException è valida come AccountBalanceViolation per loro. Alcuni addirittura sostengono test di scrittura che non sono nemmeno compilati inizialmente e trattano l'errore di compilazione come un errore normale che innesca la creazione del prossimo bit di codice aziendale. Tutto ciò che conta è che la barra sia rossa e tu scriva il codice per renderlo verde.
Se sei più preoccupato della leggibilità dell'output del test (forse teme che qualcun altro un giorno lavorerà con il codice base, o forse stai rifattando il codice legacy che non ha test), allora può essere vale la pena assicurarsi che se un test dell'unità fallisce, individuerà il problema nel modo più preciso possibile.
In questo caso, vedere un problema di riferimento nullo piuttosto che un'eguaglianza fallita è in qualche modo meno chiaro. Ma non è molto meno chiaro; Non penso che valga la pena raddoppiare la dimensione del test. In generale, però, può essere.
Se si suppone che il metodo in prova restituisca null, testarlo esplicitamente. Se non si suppone che restituisca null, restituire null è una condizione di errore e dovrebbe essere gestito come tale dal test.
Lo stesso con not-null, o davvero qualsiasi cosa.
Leggi altre domande sui tag unit-testing assertions