Approfitto di questa issue per dare consigli vari su come fare/utilizzare i test:
Scrivete PRIMA i test e poi le implementazioni:
Pensate a come devono essere utilizzate le classi e alle specifiche dei metodi (se avete dubbi chiedete please) e scrivete test che definiscano il comportamento che ci si aspetta, solo dopo iniziate a pensare all'implementazione. Se usate metodologie di sviluppo iterative (codice >> test >> codice >> test >> ...) consiglio semplicemente di provare a
cambiare l'ordine (quindi: test >> codice >> test >> codice >> ...)
I test devono essere indipententi:
Un test non deve dipendere dagli altri nè dall'ordine d'esecuzione. A seconda dell'ambiente d'esecuzione, i test possono essere eseguiti in ordine diverso e se un test utilizzasse, per esempio, il risultato di un test precedente, ci potrebbero essere problemi. Quindi, tendenzialmente, non ci devono essere attributi statici nei test.
I test dovrebbero essere i più semplici possibili:
Abbastanza autoesplicativo: preferibile avere un'asserzione per test (tecnicamente ogni metodo di test dovrebbe testare UNA sola cosa) e, nel caso se ne utilizzino di multiple, utilizzate assertAll per eseguire tutte le asserzioni anche in caso di fallimento di una delle prime (altrimenti il test si fermerebbe alla prima asserzione fallita).
(repetita iuvant) I test devono essere deterministici:
Se non è fattibile testare ogni possibile scenario (difficilmente si riesce), sceglietene un po' (possibilmente casi limite) e testate quelli. Un test casuale passato non dà alcuna informazione sul corretto funzionamento del codice, in quanto, a parità
di implementazione, potrebbe casualmente fallire e, soprattutto, non è facilmente riproducibile.
Scrivete test per debuggare:
Nel caso si presentino dei bug (o magari dovrei scrivere: "quando si presenteranno dei bug"), prima ancora di toccare codice, scrivete un test che replichi il bug per essere sicuri d'individuarne la causa e, una volta che il test sarà fallito, potrete andare a modificare il codice. L'ultima cosa che ci serve è andare a modificare codice funzionante per una nostra
ipotesi sbagliata.
Utilizzate correttamente le asserzioni:
Le asserzioni sono essenzialmente tutte del tipo: assertEquals(valore_atteso, valore_ottenuto). Questo significa che il primo valore deve essere un parametro costante del test e il secondo, invece, sarà un valore buttato fuori da qualunque cosa stiate
testando. È essenzialmente l'unico modo corretto di utilizzare le asserzioni. Utilizzarle per verificare che due variabili d'implementazione siano uguali serve solo a testare la coerenza interna della logica ma non la sua correttezza.
Pensate a come devono essere utilizzate le classi e alle specifiche dei metodi (se avete dubbi chiedete please) e scrivete test che definiscano il comportamento che ci si aspetta, solo dopo iniziate a pensare all'implementazione. Se usate metodologie di sviluppo iterative (codice >> test >> codice >> test >> ...) consiglio semplicemente di provare a cambiare l'ordine (quindi: test >> codice >> test >> codice >> ...)
Un test non deve dipendere dagli altri nè dall'ordine d'esecuzione. A seconda dell'ambiente d'esecuzione, i test possono essere eseguiti in ordine diverso e se un test utilizzasse, per esempio, il risultato di un test precedente, ci potrebbero essere problemi. Quindi, tendenzialmente, non ci devono essere attributi statici nei test.
Abbastanza autoesplicativo: preferibile avere un'asserzione per test (tecnicamente ogni metodo di test dovrebbe testare UNA sola cosa) e, nel caso se ne utilizzino di multiple, utilizzate assertAll per eseguire tutte le asserzioni anche in caso di fallimento di una delle prime (altrimenti il test si fermerebbe alla prima asserzione fallita).
Se non è fattibile testare ogni possibile scenario (difficilmente si riesce), sceglietene un po' (possibilmente casi limite) e testate quelli. Un test casuale passato non dà alcuna informazione sul corretto funzionamento del codice, in quanto, a parità di implementazione, potrebbe casualmente fallire e, soprattutto, non è facilmente riproducibile.
Nel caso si presentino dei bug (o magari dovrei scrivere: "quando si presenteranno dei bug"), prima ancora di toccare codice, scrivete un test che replichi il bug per essere sicuri d'individuarne la causa e, una volta che il test sarà fallito, potrete andare a modificare il codice. L'ultima cosa che ci serve è andare a modificare codice funzionante per una nostra ipotesi sbagliata.
Le asserzioni sono essenzialmente tutte del tipo: assertEquals(valore_atteso, valore_ottenuto). Questo significa che il primo valore deve essere un parametro costante del test e il secondo, invece, sarà un valore buttato fuori da qualunque cosa stiate testando. È essenzialmente l'unico modo corretto di utilizzare le asserzioni. Utilizzarle per verificare che due variabili d'implementazione siano uguali serve solo a testare la coerenza interna della logica ma non la sua correttezza.
Originally posted by @Andrea01Fraschini in https://github.com/paolo-chiappini/proj-ingsw-heroscimmie/issues/10#issuecomment-1502226704