Il vantaggio è che protegge il tuo DTO da futuri "miglioramenti"?
Il vantaggio è che protegge il tuo DTO da futuri "miglioramenti"?
Lasciatemi dire, prima di tutto, che la copertura per la copertura è cattiva. Scrivendo un test unitario per il costruttore della tua classe, giusto per assicurarti che NCover o dotCover vedano che il corridore ha attraversato il codice costruttore, è peggio che inutile. Se il test non fa affermazioni, le metriche di copertura del tuo build-bot danno un falso senso di sicurezza. Se fa asserzioni, allora il test dovrà cambiare se le asserzioni lo fanno mai, anche se nessun'altra linea di codice si preoccupa .
Pertanto, la risposta alla domanda per il titolo è basata su un'altra domanda: I test fanno asserzioni che gli altri elementi della tua base di codice, o dei tuoi utenti finali, si preoccuperanno?
La domanda non riguarda il livello di base del sistema in prova; un test che Add(1,2) == 3 può essere utile, se è quello che deve fare il codice e devi assicurarti che lo faccia sempre. È anche utile se sei TDDing (quale IMO dovresti essere), perché quando fai questa asserzione, il codice che lo renderà vero non esiste ancora. In TDD, indipendentemente da quanto possa essere semplice un'azione, se hai bisogno di una riga di "codice dello sviluppatore finale" (non incorporata nella lingua o in una libreria di terze parti) per eseguire un'azione, hai bisogno di un'asserzione che dimostri hai scritto quella riga di codice correttamente.
Leggi altre domande sui tag tdd unit-testing design java