Questo post verte soltanto su un aspetto se volete marginale – ma molto utile – della IDE che uso per progetti PHP / Python / Groovy: IntelliJ IDEA di JetBrains: come la IDE ci aiuta a non commettere errori del tipo “leggere valori di variabili private”.
Sommario
Scrivere un test (Specification) con Spock
Prendo l’esempio dal bel video tutorial di Spock di Trisha Gee che vi linko qui sotto:
Il codice è suo e qui lo analizzo soltanto (faccio solo piccole, innocue personalizzazioni). Precisamente: descrivo un po’ più in dettaglio un comportamento della IDE che mi aiuta a scrivere meglio il software.
Sto scrivendo (più precisamente: analizzando il funzionamento di) una classe di test con Spock che riguarda una classe Groovy Polygon (posto gli screenshot perché risulta evidente il comportamento della IDE di cui voglio parlare): la classe ha una sola proprietà che si chiama numberOfSides, il numero di lati del poligono, che è un attributo privato:
Ora scriviamo un test (nel gergo di Spock i test si chiamano Specifications) che controlla se l’attribuzione del numero di lati del poligono funziona come ci aspettiamo; utilizziamo il costrutto given – when – then (che è l’oggetto di questa parte del tutorial di Trisha):
Notiamo che la proprietà numberOfSides dell’oggetto è evidenziata; passando con il mouse sopra la parte messa in risalto, la IDE ci informa sul perché di questa evidenziazione (Access to ‘numberOfSides’ exceedes its access rights):
Stiamo infatti tentando di accedere ad un valore di una variabile privata da un’istanza della classe e non dall’interno della classe stessa.
Potremmo correggere questa cosa in due modi: o attribuendo il qualificatore public alla variabile oppure definendo un getter. Percorro questa seconda via; aggiungo quindi il metodo getNumberOfSides() alla classe – è una costruzione standard: get + nome della variabile (con la regola CamelCase):
int getNumberOfSides() {
return numberOfSides
}
Ecco che la IDE non mette più in evidenza la proprietà numberOfSides:
Si noti che la IDE riconosce la presenza di un getter secondo la convenzione espressa sopra – se non seguo la convenzione la IDE tornerà a segnalare il problema. Nota che non ho cambiato la scrittura (non ho utilizzato esplicitamente il getter nell’assegnazione, ma l’ho lasciata così com’è) ma Groovy lo farà durante il build, sostituendo all’assegnazione diretta l’invocazione del getter come risulta dal tooltip che viene visualizzato quando passiamo con il mouse sopra l’istruzione:
Non ci resta che lanciare il test cliccando sulla freccetta verde accanto alla definizione del metodo (notare come sia possibile utilizzare stringhe custom per definire il nome dei metodi, una caratteristica molto utile per documentare ciò che il test vuole fare):
Commenti recenti