I JavaBeans semplici con getter e setter semplici devono essere testati unitamente ??Gli oggetti del dominio e i JavaBeans semplici devono essere testati unitamente?
E i bean con una certa logica in getter e setter?
Non si dovrebbe scrivere test che:
Lo stesso vale per gli oggetti .NET che hanno solo proprietà (a volte chiamati oggetti "Info").
In un mondo ideale si avrebbe una copertura di prova del 100%, ma in pratica questo non accadrà. Quindi spendi i soldi del cliente dove aggiungerà il massimo beneficio, cioè scrivere test per classi con stato e comportamento complessi.
Se il JavaBean diventa più interessante, è possibile aggiungere un caso di test in un secondo momento. Uno dei problemi più comuni associati a Unit Testing/TDD è l'errata convinzione che tutto debba essere perfetto per la prima volta.
Se non vale la pena provare, non vale la pena scriverlo.
Ciò non significa sempre che si dovrebbero scrivere test. A volte vuol dire che devi cancellare il codice. Hai bisogno di questi fagioli? Realmente fanno qualcosa di importante? Se ne hai bisogno, dovresti scrivere dei test. In caso contrario, elimina il codice e vivi una vita più felice sapendo di avere meno da mantenere.
Basta testare le cose che si desidera funzionare correttamente.
(Mi dispiace per chi mi ha donato quella citazione da)
penso che è una di quelle domande che tutti si chiede a se stesso (se stessa).
Ma considera questo: la logica interna degli accessor è semplicemente semplice, ma potrebbe cambiare in futuro, e - cosa molto più importante - ti sentirai libero di cambiarlo in qualsiasi cosa desideri se hai dei test per i metodi. Quindi, ottieni libertà e sicurezza per mezzo di un paio di testicoli. Sembra un buon affare, eh?
se è solo un getter/setter senza modificare nulla ai valori, direi che non c'è bisogno di test. Se fa qualche logica, alcuni semplici test di unità forniranno un po 'di sicurezza.
Come si può smentire in modo sicuro il codice non testato? Cosa succederà quando il tuo bean pojo cambia se non hai test? Stai creando un Anemic Domain Model?
È necessario testare le cose che hanno un significato. Generalmente getter e setter non contengono alcuna logica e sono semplicemente usati in Java per la mancanza di proprietà. Penso che testarli sia tanto stupido quanto controllare che Java restituisca un valore ogni volta che si valuta "a.x".
Se l'accessor ha una logica, spetta a te decidere la soglia. Se la tua squadra è pigramente. è meglio testare tutta la logica. Se è più disciplinato, è meglio trovare un rapporto che non ti porti a scrivere troppi esami standard.
Come già detto Maxim: l'esecuzione di test non aggiungerà funzionalità aggiuntive all'applicazione, ma consentirà di apportare modifiche con maggiore sicurezza. Per determinare quali classi/metodi devono essere testati, mi pongo sempre due domande:
Se entrambe le domande hanno una risposta affermativa, è necessario un test di unità.
A mio parere, lo scopo della scrittura dell'unità test è testare la logica aziendale dell'unità in prova. Pertanto, se non esiste una logica di business (ad esempio, quando un getter restituisce semplicemente un valore o un setter lo imposta), non ha senso scrivere un test. Se, tuttavia, c'è qualche logica (getter modifica i dati in qualche modo prima di restituirli) allora sì, dovresti fare un test unitario. Come regola generale, credo che non si debbano scrivere test per i bean che non contengono alcuna logica di business.
Se ha un'interfaccia esterna e contiene il codice scritto da una persona (al contrario di essere generato automaticamente dall'IDE o dal compilatore), deve essere definitivamente testato.
Se una o entrambe queste condizioni non reggono, allora si tratta di un'area grigia e si riduce a una questione di "cintura e bretelle" - tipo di quanto si senta il bisogno di essere attento.
Un'altra regola empirica (simile a ciò che altri hanno detto) è "testare qualsiasi cosa che potrebbe eventualmente rompersi". Per me che esclude getter e setter generati automaticamente, ma include quelli scritti a mano che contengono una certa logica.