Esiste un framework di unit test di Java che testa automaticamente getter e setter? [chiuso]

StackOverflow https://stackoverflow.com/questions/108692

  •  01-07-2019
  •  | 
  •  

Domanda

C'è un noto dibattito in Java (e in altre comunità, ne sono sicuro) sull'opportunità di testare metodi banali getter / setter. Di solito, ciò riguarda la copertura del codice. Concordiamo sul fatto che si tratta di un dibattito aperto e non proviamo a rispondere qui.

Ci sono stati diversi post sul blog sull'uso di Java reflection per testare automaticamente tali metodi.

Qualche framework (ad esempio jUnit) fornisce una tale funzionalità? per esempio. Un'annotazione che dice "questo test T dovrebbe testare automaticamente tutti i getter / setter in classe C, perché asserisco che sono standard".

Mi sembra che aggiungerebbe valore e, se fosse configurabile, il 'dibattito' verrebbe lasciato come opzione all'utente.

È stato utile?

Soluzione

Unitils fa questo con il metodo statico assertRefEquals .

Altri suggerimenti

Non sono a conoscenza di alcuna libreria o classe prontamente disponibile che lo faccia. Ciò può essere dovuto principalmente al fatto che non mi interessa, dal momento che sono dalla parte di contrastare fortemente tali test. Quindi, anche se hai chiesto lì deve essere un po 'giustificato per questa vista:

Dubito che getter e setter di autotest avvantaggino la qualità del codice o la copertura: entrambi questi metodi sono utilizzati da altri codici (e testati lì, ad esempio coperti al 100%) o non utilizzati affatto (e potrebbero essere rimossi). Alla fine lascerai getter e setter perché sono usati dal test ma da nessun'altra parte nell'applicazione.

Dovrebbe essere facile scrivere un test del genere, ad es. con Apache Commons BeanUtils, ma dubito che tu ne abbia davvero bisogno se hai buoni test altrimenti.

Ho creato il progetto OpenPojo per risolvere questo esatto problema.

Il progetto ti consente di validare:

  • Applica lo standard di codifica Pojo (ovvero tutti i campi privati ??o nessuna variabile nativa, ecc.)
  • Applica il comportamento di Pojo (ad es. setter esegue SOLO l'impostazione, nessuna trasformazione, ecc.)
  • Convalida identità Pojo (ovvero utilizza l'uguaglianza basata su annotazione e la generazione di hashcode)

Vedi Tutorial

Nella maggior parte dei casi setter e getter fanno di più solo impostando e ottenendo un campo interno. Un oggetto deve verificare le regole interne per contenere solo valori validi. Ad esempio

  • sono possibili valori nulli?
  • sono possibili stringhe vuote?
  • o valori negativi?
  • o valore zero?
  • o i valori di un elenco sono validi?
  • o esiste un valore massimo?
  • o esiste una precisione massima sui valori BigDecimal?

Il test unitario dovrebbe verificare se il comportamento è corretto in caso di valori non validi. Questo non può essere automatizzato.

Se non si dispone di logica sul setter e sul getter, è necessario utilizzarlo ovunque nell'applicazione. Scrivi un test in cui il tuo oggetto è un parametro per un test più complesso. Puoi testarlo quindi con valori diversi dall'elenco.

Metti alla prova la tua logica aziendale e non il getter e il setter. Il risultato dovrebbe anche coprire il getter e il setter. I metodi dovrebbero essere qualsiasi risultato nella tua logica aziendale anche se hai solo una biblioteca pubblica. Se il getter e il setter non hanno copertura del codice, rimuoverlo.

Ho fatto qualcosa del genere. Una semplice classe Java che prende un oggetto e verifica tutti i metodi getter e setter. http://sourceforge.net/projects/getterandsetter/

Penso che dovresti evitare il più possibile i metodi getter e setter, ma finché sono in giro e ci vogliono due righe per testarli, è una buona cosa farlo.

Favorirò la progettazione OO rispetto alla copertura del codice e vedrò se non riesco a spostare quei campi nella classe che li necessita. Quindi proverei a vedere se quei getter e setter possono essere rimossi, come suggerito prima. getter e setter sono incapsulamento di rottura .

Suppongo che questa libreria sia la risposta alla tua domanda

verifica tutti i valori iniziali del bean, i setter , i getters , hashCode (), equals () e toString () . Tutto quello che devi fare è definire una mappa di proprietà / valore predefinite e non predefinite.

Può anche testare oggetti che sono bean con costruttori aggiuntivi non predefiniti.

Sto provando openpojo

Ho calciato le gomme e sembra fare il lavoro.

  1. Ti permette di controllare tutti i pojo nel tuo progetto.
  2. Sembra che controlli le migliori pratiche su pojo

Controlla questo tutorial per un rapido avvio Tutorial

Rispondere al commento precedente su @ me qui per la mia reputazione:

  

In prospettiva, non scrivere getter / setter non ha alcun senso. Le uniche opzioni per impostare i campi privati ??sono avere setter espliciti, impostarli nel proprio costruttore o impostare indirettamente tramite altri metodi (rinviare funzionalmente il setter in un altro posto). Perché non usare setter?

Beh, a volte, non è necessario che il campo sia privato (scusate se il mio inglese non è molto buono). Spesso, scriviamo il nostro software in quanto era una libreria e incapsuliamo i nostri campi (i nostri campi di logica aziendale) con getter / setter non necessari.

Altre volte, quei metodi sono effettivamente necessari. Quindi, ci sono due possibilità:
1. C'è una logica aziendale al loro interno. Quindi dovrebbero essere testati, ma non sono veri e propri getter / setter. Scrivo sempre quella logica in altre classi. E i test verificano che altre classi, non il POJO .
2. Non c'è. Quindi, non puoi scriverli a mano, se puoi. Ad esempio, un'implementazione per l'interfaccia successiva può essere completamente generata automaticamente (e anche in fase di esecuzione!): 

interface NamedAndObservable {
  String getName();
  void setName(String name);
  void addPropertyChangeListener(PropertyChangeListener listener);
  void addPropertyChangeListener(String propertyName,
                                 PropertyChangeListener listener);
}

Quindi prova solo ciò che è scritto a mano. Non importa se si tratta di un getter / setter.

Non scrivo casi di test per ogni proprietà, ma invece collaudo tutti i setter / getter in un singolo caso di test usando reflection / introspector per determinare i tipi. Ecco una grande risorsa che mostra questo:

http://www.nearinfinity.com/blogs/scott_leberknight/do_you_unit_test_getters.html

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top