Ciao a tutti!
Sto svolgendo dei metodi di test per un'applicazione. Siccome è molto lungo istanziare ogni classe con più parametri d'ingresso oltre quelli che mi interessano (es. se ho classe Persona e voglio creare più persone con eta diversa e poi fare le verifiche sulla loro età, non mi importa il loro cognome...).
Mi chiedev se esiste qualche modo per invocarli dando in input al costruttore qualcosa come null (dato che null non lo accetta in compilazione...).
Cosa posso mettere?
Ad esempio
public class Persona {
...
public Persona( String nome, String cognome, int eta ) {...}
...
}
Nel metodo di Test vorrei fare qualcosa del genere
....
public void testPersona {
Persona p = new Persona(null, null, 30);
Persona q = new Persona(null, null ,34);
assertTrue(64, p.getEta() + q.getEta() );
}
...
wingman87
09-07-2009, 00:18
Dai a tutti un nome farlocco, sempre lo stesso... O se preferisci una stringa vuota.
banryu79
09-07-2009, 09:21
Visto che hai la neccessità di eseguire dei test sulle classi che scrivi (pratica buona e giusta) perchè non ti appoggi a qualche libreria per lo Unit Testing?
Ad esempio in NetBeans c'è JUnit.
Se non sai cos'è la pratica chiamata "unit testing" in rete trovi zillionate di risorse e spiegazioni.
Tanto per darti un esempio (usando una classe di fantasia).
La classe da testare:
public class Persona
{
String nome;
String cognome;
GregorianCalendar dataNascita;
public Persona(String n, String c, GregorianCalendar d)
{
nome = n;
cognome = c;
dataNascita = d;
}
public int getEta()
{
GregorianCalendar today = getToday();
return today.add(Calendar.YEAR, -dataNascita.get(Calendar.YEAR));
}
@Override
public String toString()
{
Object[] values = {nome, cognome, getEta()};
String pattern = "nome: {0}, cognome: {1}, eta': {2}";
return MessageFormat.format(pattern, values);
}
protected GregorianCalendar getToday()
{
Date now = new Date();
GregorianCalendar today = new GregorianCalendar();
return today.setTime(now);
}
}
Unit test della classe Persona:
import org.junit.After;
import org.junit.Before;
import org.junit.Test;
import static org.junit.Assert.*;
/**
* Unit test for class Persona
*/
public class PersonaTest
{
Persona marco, giorgio, luca;
@Before
public void setUp()
{
marco =
new Persona("Marco", "Rossi", new GregorianCalendar(1979,0,15));
giorgio =
new Persona("Giorgio", "Rossi", new GregorianCalendar(1984,5,7));
luca =
new Persona("Luca", "Bianchi", new GregorianCalendar(1999,11,24));
}
@After
public void tearDown()
{
marco = giorgio = luca = null;
}
/**
* Test of getEta method, of class Persona
*/
@Test
public void testGetEta()
{
System.out.println("*PersonaTest - testGetEta()");
assertEquals(30, marco.getEta());
assertEquals(25, giorgio.getEta());
assertEquals(10, luca.getEta());
}
/**
* Test of toString method, of class Persona.
*/
@Test
public void testToString()
{
System.out.println("*PersonaTest - testToString()");
String expected = null;
expected = "nome: Marco, cognome: Rossi, eta': 30";
assertEquals(expected, marco.toString());
expected = "nome: Giorgio, cognome: Rossi, eta': 25";
assertEquals(expected, giorgio.toString());
expected = "nome: Luca, cognome: Bianchi, eta':10";
assertEquals(expected, luca.toString());
}
Disclaimer: non ho compilato il codice percui potrebbe non essere corretto; serve solo per darti l'idea.
Il punto è che nella classe per lo unit test di Persona che ho scritto, come vedi ci sono due metodi 'setUp' e 'tearDown'.
'setUp' viene chiamato prima subito prima di invocare ogni metodo di test; 'tearDown' viene chiamato subito dopo l'invocazione di ogni metodo di test.
Qui li ho sfruttati per costruire 3 reference di Persona che vengono usate nel test, e subito dopo vengono resettate.
Questo permette di evitare la propagazione di eventuali "side-effect" agli atri metodi di test, che sono così ben isolati.
Se non ti interessa diversificare in base ai campi 'nome' e 'cognome' (ma per far funzionare l'oggetto, ovvero per costruirlo, sono neccessari) basta fare una cosa così, nella classe di test:
public class PersonaTest
{
Persona persona1, persona2, persona3;
@Before
public void setUp()
{
String s= "";
persona1 = new Persona(s, s, new GregorianCalendar(1979,0,15));
persona2 = new Persona(s, s, new GregorianCalendar(1984,5,7));
persona3 = new Persona(s, s, new GregorianCalendar(1999,11,24));
}
@After
public void tearDown()
{
persona1 = persoan2 = persona3 = null;
}
....
Se ti ritrovi ad avere una classe con molti parametri nel costruttore, puoi considerare un Builder Pattern.
Ha diversi vantaggi, tipo permettere alla tua classe di rimanere immutabile, simulare parametri opzionali e rendere più flessibile la costruzione di un oggetto di quel tipo.
Ovviamente ha lo svantaggio di aumentare la complessità del codice.
Esempio copia/incollato (non è farina del mio sacco):
// Builder Pattern
public class NutritionFacts {
private final int servingSize;
private final int servings;
private final int calories;
private final int fat;
private final int sodium;
private final int carbohydrate;
public static class Builder {
// Required parameters
private final int servingSize;
private final int servings;
// Optional parameters - initialized to default values
private int calories = 0;
private int fat = 0;
private int carbohydrate = 0;
private int sodium = 0;
public Builder(int servingSize, int servings) {
this.servingSize = servingSize;
this.servings = servings;
}
public Builder calories(int val) {
calories = val;
return this;
}
public Builder fat(int val) {
fat = val;
return this;
}
public Builder carbohydrate(int val) {
carbohydrate = val;
return this;
}
public Builder sodium(int val) {
sodium = val;
return this;
}
public NutritionFacts build() {
return new NutritionFacts(this);
}
}
private NutritionFacts(Builder builder) {
servingSize = builder.servingSize;
servings = builder.servings;
calories = builder.calories;
fat = builder.fat;
sodium = builder.sodium;
carbohydrate = builder.carbohydrate;
}
}
E poi lo usi cosi...
NutritionFacts cocaCola = new NutritionFacts.Builder(240, 8).
calories(100).sodium(35).carbohydrate(27).build();
Ma se hai solo 3 parametri come nell'esempio che hai riportato non è il caso...
Oceans11
09-07-2009, 15:10
Mi chiedev se esiste qualche modo per invocarli dando in input al costruttore qualcosa come null (dato che null non lo accetta in compilazione...).
Veramente??? :eek:
scusate ma cado proprio dalle nuvole....e perchè mai??
Io pensavo che al massimo lanciasse una NullPointer nel caso in cui ci si riferisce alla variabile = null, infatti ho fatto una prova (banalissima) e compila senza errori:
public class Persona {
String n;
int e;
public Persona( String nome, int eta ) {
n=nome;
e = eta;
}
public static void main(String[] args) {
Persona p = new Persona(null, 50);
}
}
banryu79
09-07-2009, 15:33
Veramente??? :eek:
scusate ma cado proprio dalle nuvole....e perchè mai??
Io pensavo che al massimo lanciasse una NullPointer nel caso in cui ci si riferisce alla variabile = null, infatti ho fatto una prova (banalissima) e compila senza errori:
Sì sì, infatti, credo che l'utente intendesse la possibilità di fregasene dei primi due parametri nel test senza dover "inquinare" la classe mettendo degli ulteriori costruttori solo per gestire questa esigenza. Chiaro che puoi sempre e comunque passare una reference che vale null, di certo il compilatore non te lo vieta.
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.