Posso verificare l'esistenza di un'annotazione in un unit test?


9

Ho una gerarchia di classi Java che sono formate da una classe astratta e da N estensioni. Nella classe astratta ho un metodo che è annotato con un'annotazione @Remove. Anche se non avremo eccezioni di non falliremo velocemente se questa annotazione viene rimossa, potremmo uscire di eccezioni di memoria, quindi vorrei essere sicuro che noteremo il più velocemente possibile se questa annotazione scompare in alcuni refactoring.

Sto cercando di creare GUTS (buoni test unitari), quindi ho pensato di poter documentare questo "requisito tecnico" nei miei test, con un caso di test che lo afferma.

Ma questa non è una funzionalità, è un dettaglio di implementazione e non è collegata al comportamento del metodo (il metodo potrebbe essere vuoto, ma deve esistere e deve essere annotato).

Va bene creare un test per questo o c'è un altro modo per verificare l'esistenza di questa annotazione?


1
Stai chiedendo come farlo o se farlo è una buona pratica di ingegneria del software? La risposta a quest'ultima è sì. I test verificano la qualità della tua base di codice; non controllano necessariamente il comportamento attuale . È perfettamente bene avere test che verificano le condizioni intese a favorire il buon comportamento futuro .
Kilian Foth,

Risposte:


5

Sì, crea un test unitario. Stai dicendo che se l'annotazione viene rimossa, puoi eliminare i bug di memoria durante la produzione. Sarebbe un bug assassino. Lasciare che ciò accada a causa dell'idea che i test dovrebbero in qualche modo essere limitati è controproducente. I test dovrebbero verificare la correttezza in tutti i sensi. Prima si rileva il possibile problema, meglio è quindi avere un test unitario e non riuscire a costruire CI è il modo solido per prevenire il bug. Cercare di inventare un altro meccanismo per impedire l'introduzione di un tale bug non sembra valga la pena. Ogni nuovo sviluppatore dovrà avere una spiegazione di come gestire il "caso speciale" di nessuno dei test di correttezza funzionale. Molto probabilmente questo non è un buon uso del tempo degli sviluppatori.

Modifica È probabile che i team che eseguono BDD separino i test funzionali aziendali dai test tecnici come i test delle prestazioni. In genere i team hanno diversi tipi di test, inclusi i test di integrazione eseguiti meno frequentemente rispetto ai test di logica aziendale principale. Questo di solito viene fatto con i profili di build in modo che gli sviluppatori nel loro flusso possano eseguire frequentemente test rapidi di logica aziendale e test di integrazione più lenti prima di eseguire il commit del codice. La build CI eseguirà tutti i test.


2

Quando una funzione critica viene implementata usando una tecnica dichiarativa come questa, tendo a preferire l'uso di un test di integrazione che includa la parte del framework che riconosce la dichiarazione. Questo ti protegge da cambiamenti nel comportamento dei quadri, incomprensioni dell'effetto della dichiarazione e così via. Il semplice test della presenza dell'annotazione non garantisce alcun comportamento specifico.


Ciao! Questo è interessante, come controlleresti il ​​comportamento dell'annotazione @remove, per esempio?
JSBach,

Sfortunatamente, non ho abbastanza familiarità con EJB per rispondere a questa domanda - tendo ad evitare di lavorare con la tecnologia proprio perché trovo difficile scrivere buoni test per.
Jules,

L'idea di questa annotazione è che dice al contenitore che il bean potrebbe essere rimosso. Purtroppo è difficile testare questo comportamento :(
JSBach,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.