FabioJ ha scritto:
Scrivere (con Eclipse) una classe di test Junit per la classe
Persone (dal Quiz di preparazione alla prima verifica)
• In particolare testare il metodo int contaOmonimiDi(String nome)
• Scrivere il codice del metodo int contaOmonimiDi(String nome)
• Eseguire la classe di test Junit (se il test fallisce, correggere il
metodo sotto test e far girare nuovamente la classe di test)
public class Persone {
[ .... ]
}
Ok, la classe Persone rappresenta semplicemente un elenco di nomi di lunghezza fissa .. né più né meno.
Vediamo di spiegarti come si dovrebbe affrontare il testing. Secondo la metodologia TDD (test-driven development) lo sviluppo dovrebbe avvenire così: PRIMA si scrivono gli unit-test e poi DOPO si scrivono le implementazioni che sono sottoposte a test.
A prima vista sembrerebbe un controsenso, come si può testare qualcosa che non esiste ancora? Innanzitutto servono le specifiche sull'elemento da testare. E le abbiamo. Sappiamo che ci sarà un metodo contaOmonimiDi che riceve un String (nome) e restituisce un int (numero di omonimi). Questo è sufficiente, almeno a livello concettuale.
Poi è chiaro che se vuoi scrivere una classe di test che "compili", la classe e il metodo sottoposti a test (Persone e contaOmonimiDi) chiaramente devono perlomeno già esistere, anche se incomplete. Se non ci fossero, la classe di test non ti compila proprio per niente!
Molto probabilmente hai già idea di cosa vorrà dire "contare" gli omonimi dato un nome in input. Per il momento NON pensare alla implementazione concreta, NON preoccuparti di questo. Anzi, l'obiettivo iniziale dovrebbe essere quello di far
fallire TUTTI i test. Quindi in contaOmonimiDi fai lanciare una bella eccezione:
public int contaOmonimiDi(String nome) {
throw new RuntimeException("non implementato");
}
In questo modo TUTTI i test falliranno di certo. Ripeto, non preoccuparti che ora c'è una implementazione "farlocca".
Ora pensa ai casi di test. Quali sono? Ce ne sono diversi, tra cui anche dei casi "limite".
a) Dato un oggetto Persone che contiene { "Mario", "Roberto", "Mario" } tu ti aspetti che contaOmonimiDi con "Mario" dia 2
b) Dato un oggetto Persone che contiene { "Mario", "Roberto", "Mario" } tu ti aspetti che contaOmonimiDi con "Gianni" dia 0
Ma si dovrebbero anche considerare casi "limite" in cui ci sono dei null. Cosa dovrebbe succedere se nell'array di Persone non sono state messe delle stringhe a certi indici? La tua implementazione NON dovrà fallire (es. con NullPointerException) ma ragionevolmente dare il conteggio corretto (anche se fosse es. 0).
A questo punto crea un metodo di test. Sui NOMI dei metodi di test si è sempre discusso molto e ci sono diverse scuole di pensiero. Non c'è una convenzione unica e comune. A riguardo puoi leggere
https://dzone.com/articles/7-popular-unit-test-naming
Quindi in una classe PersoneTest metti:
@Test
public void verificaContaOmonimiDiConNomeDuplicato() { .... }
@Test
public void verificaContaOmonimiDiConNomeNonPresente() { .... }
Purtroppo in italiano non vengono granché i nomi. In inglese verrebbero meglio (vedi il link sopra). Ma del nome non ti preoccupare "troppo" in questo momento. Prova a scrivere i test per i due casi a) b) descritti sopra.