[CICLO 1] Storie e divisione in task

[cionci]

cisc: guarda nel thread [Diamonds] Si parte!...

[fek]

Benissimo. Aspetto la mail dalla build machine e faccio il sign off.

A questo punto, quando arriva Vicius, possiamo discutere anche una nuova storia da aggiungere a questo ciclo, visto che abbiamo ancora 8gg a disposizione.

[cisc]

ragazzi, una domanda, ma devo aggiungere il sound a Game.java?

[fek]

Originariamente inviato da cisc

ragazzi, una domanda, ma devo aggiungere il sound a Game.java?

Si', alla partenza del gioco.

[cisc]

fatto, lanciando Game viene riprodotto diamond.wav all'inizio, adesso il tutto è abbastanza minimale, posso aggiungere altre features (tipo loop, stop, rewind) o vado contro il principio di fare solo quello che serve?

[fek]

Originariamente inviato da cisc

fatto, lanciando Game viene riprodotto diamond.wav all'inizio, adesso il tutto è abbastanza minimale, posso aggiungere altre features (tipo loop, stop, rewind) o vado contro il principio di fare solo quello che serve?

Ti sei gia' risposto

Ho provato sulla mia macchina e funziona.
Ho fatto un po' di refactoring delle classi Texture, Game e Audio. Se avete voglia fate un diff di questi file usando SVN e guardate come sfruttando i test, ho semplificato un po' il codice, partendo da codice funzionante e testato. E' un tipico Refactoring, e potrebbe essere interessante dargli un'occhiata.

[VICIUS]

Punto della situazione:
- Il codice per tutti i task con relativi test sono nel repository.
- JUnit ci da luce verde per procedere.
Tutto questo in meta del tempo previsto. Ottimo lavoro

Ora non ci resta che aspettare il commit del refactoring di cdimauro e poi possiamo procedere con un'altra storiella.
Mentre aspettiamo prendete confidenza con eclipse e ant che non fa mai male.

ciao

[cionci]

Il compilatore mi ritorna questo warning:
Unreachable catch block for TextureNotFoundException. This exception is never thrown from the try statement body

Da quello che ho capito il compilatore analizza le chiamate fatte nel try e non trova nessun punto nel codice che potrebbe lanciare l'eccezione TextureNotFoundException...
In pratica si ottiene questo warning ogni volta che si crea una nuova texture nel try... Comunque è vero che all'interno del costruttore non viene mai lanciata una eccezione di quel tipo, ma è anche vero che un'eccezione di quel tipo può essere lanciata da una funzione richiamata dal costruttore...quindi non vedo il perchè di questo assurdo warning...

La compilazione ed i test comunque terminano correttamente...ma ogni volta ricorda che sono questi warning...

[cionci]

Ora è sparito, forse perchè sono andato a vedere il codice della classe Texture e ho trovato dove viene lacniata la possibile eccezione... A questo punto penso che sia un parser interno ad Eclipse ad avere generato il warning e non il compilatore

[fek]

Mancano i task di TigerShark e cidimauro all'appello.

[cdimauro]

Fatto.

C'è anche un po' di refactoring del codice...

[fek]

Originariamente inviato da cdimauro

Fatto.

C'è anche un po' di refactoring del codice...

Abbiamo un volontario anche per il task 2!

Sempre che il responso della build machine sia positivo. Attendiamo.

[^TiGeRShArK^]

toccando palle.....stasera dovrei committare, scusate il ritardo

[fek]

Tutti i task sono completati.
Ho fatto un pesante refactoring della classe Game.java, puo' essere interssante dare un'occhiata alla differenza fra le due ultime versioni: ci sono un po' di "Extract Method" uno dopo l'altro, ed un refactoring verso "Template Method".

Ho aggiunto la classe Engine.java di cidimauro ed ho fatto un po' di refactoring per supportare la testabilita' della classe stessa. La soluzione e' tutto fuorche' elegante, c'e' un code smell grosso come una casa e il codice urla per farsi applicare un bel refactoring. Compito a casa per voi

Non preoccupatevi se non vi viene in mente nulla, questo refactoring non e' per nulla banale.

[Vifani]

Mamma mia quanto è brutta quella varianile "testing". Tra l'altro testa una cosa sbagliatissima: è un test di nessuna utilità perché teoricamente va a vedere solo se la risoluzione selezionata è supportata dal sistema. Peccato che il sistema sia il server della cui compatibilità ce ne possiamo tranquillamente fregare (non so che scheda monti, ma è del tutto irrilevante). La sua unica utilità attuale è di verificare se il metodo di ricerca delle DisplayMode disponibili è corretto.

Io separerei il concetto di Engine dal concetto di Window. In questo modo si può testare la creazione dell'Engine, senza quella della finestra che è intestabile.

[cionci]

Concordo sulla separazione...

[fek]

Originariamente inviato da Vifani

Mamma mia quanto è brutta quella varianile "testing". Tra l'altro testa una cosa sbagliatissima: è un test di nessuna utilità perché teoricamente va a vedere solo se la risoluzione selezionata è supportata dal sistema. Peccato che il sistema sia il server della cui compatibilità ce ne possiamo tranquillamente fregare (non so che scheda monti, ma è del tutto irrilevante). La sua unica utilità attuale è di verificare se il metodo di ricerca delle DisplayMode disponibili è corretto.

Io separerei il concetto di Engine dal concetto di Window. In questo modo si può testare la creazione dell'Engine, senza quella della finestra che è intestabile.

Testare qualcosa e' meglio che non testare nulla. Da qui il bruttissimo flag 'testing', che grida per il refactoring. Cio' che si vuole testare e' il fatto che la sequenza di inizializzazione sia chiamata nell'ordine corretto, non che la risoluzione sia disponibile. Da OpenGL abbiamo la quasi-garanzia che se la sequenza e' corretta, allora lui si comporta correttamente, ed e' cio' che vogliamo testare.

Comunque si', questi problemi e anche i problemi che ha avuto cidimauro sono dovuti alla classe Engine che tenta di fare due cose (OpenGL e Window), e quando si tenta di fare due cose, c'e' sempre qualcosa che non va. Vanno separate, e va creata una classe minimale attorno a OpenGL che racchiuda solo quello che non puo' essere testato, poi serve un suo mock che non inizializza OpenGL, ma che si comporta logicamente allo stesso modo con gli stessi servizi, di modo da essere usata per i test.

Benvenuti nel mondo delle Mock class per i test

Chi se ne occupa? Lo facciamo assieme perche' non e' banale, perche' i test devono restare invariati, deve solo cambiare il codice che li implementa.

Edit:
E' interessante notare il processo che abbiamo seguito in questo caso:

- Siamo partiti da codice gia' scritto che inizializza OpenGL
- Lo abbiamo separato in una classe perche' volevamo testarlo
- Abbiamo trovato dei problemi di testing e cercato una soluzione
- Abbiamo implementato la prima soluzione che ci veniva in mente commettendo anche peccati mortali se necessario (make it work)
- Avere la soluzione brutta scritta davanti ci ha suggerito una soluzione piu' elegante (make it nice), separando le due classi
- Implementeremo la soluzione piu' elegante, sapendo che i test ci diranno quando sbaglieremo qualcosa

Ma non e' bello fare Refactoring? Ti mette in pace col mondo

[cdimauro]

A me interesserebbe (anche perché è il task che mi ha coinvolto in prima persona), ma per lo più lavoro a Diamonds di giorno e difficilmente nel weekend: il mio status è compatibile con questi obiettivi?

[fek]

Originariamente inviato da cdimauro

A me interesserebbe (anche perché è il task che mi ha coinvolto in prima persona), ma per lo più lavoro a Diamonds di giorno e difficilmente nel weekend: il mio status è compatibile con questi obiettivi?

Tu prova. Fai un passettino di refactoring per volta, magari aggiungi qualche test e vedi che ne esce. Poi qualcun altro continuera' il tuo lavoro.

[fek]

Possiamo chiudere questo topic e questa storia?