#dancer::test

[cym0n-blog]

Redirezione non è risposta

Risolto l'antipatico problema di ieri.

La questione era che, in caso di vittoria, la chiamata click chiede che venga fatto un redirect sulla pagina di vittoria. Il redirect veniva verificato da una apposita response_redirect_location_is, peccato che questo tipo di test NON fa scattare anche la chiamata che sottostà al redirect. Peccato che, nel mio caso, fosse la pagina win quella a far scattare tutti i meccanismi di effettiva concretizzazione della vittoria.

Forzando, dopo aver verificato la redirect, un test response_status_is sulla chiamata diretta win a quel punto il sistema ha chiuso il giro e mi ha dato la situazione esatta.

Due cose rimangono aperte: la prima, una scelta architetturale che mi lascia perplesso, ovvero il fatto che win e gameover scattano in due momenti diversi. Forse è più giusto quello che fa gameover, ovvero prima elabora la sconfitta e poi va a proporre la pagina di finale. 

La seconda, il fatto che il test ha bisogno di un po' di refactoring. I due scenari di vittoria e sconfitta andrebbero accorpati in un solo file, con parametri da linea di comando.

Ma, rispetto al resto, sono inezie. La verità è che posso già pensare di riportare su master tutto il lavoro e anche metterlo su openshift.

[cym0n-blog]

Il test definitivo

Mi sono messo d'impegno e alla fine ho realizzato il sistema di test definitivo. Ora vengono considerate all'incirca tutte le navigazioni interessanti. Ho addirittura fatto in modo che il sistema non attinga alle storie reali, ma a una directory ad hoc, dove ho ridisegnato una missione in modo che sia raggiungibile in tempi rapidi la vittoria o la sconfitta, così da arrivare a considerare anche quegli stati.

Ho anche risolto un fastidioso bug sul supporto dovuto alla sbagliata configurazione della colonna del DB, il che non è un male.

Ora mi rimane solo un test fastidiosissimo che fallisce alla vittoria e in cui non riesco proprio a raccapezzarmi, anche considerato che, facendo la navigazione, funziona tutto correttamente...

[cym0n-blog]

Refactoring con classe

Fino a oggi avevo una classe ..Element::User che era una classe vera e propria, che controllava l'oggetto user, è una classe Result::User che era, naturalmente la classe Result generata dallo schema del DB.

Andando avanti a sviluppare mi è risultato sempre più ovvio come la classe Element::User non fosse altro che un proxy verso il modello. Ho deciso quindi di fare del refactoring affinché tale classe cessi di esistere e tutto sia gestito dal Result.

Visto che comunque non è che User abbia molta logica è stato tutto estremamente lineare. La maggior parte dei metodi (quelli brutalmente proxy) sono stati semplicemente eliminati mentre gli altri copincollati con poche modifiche nel diverso punto.

L'unica logica un po' pesante su cui ho dovuto lavorare è stata quella contenuta nel new della classe Element::User che si portava dietro, ovviamente diversi ragionamenti. Tutta quella roba l'ho spostata in un metodo dei controllers, anche lì copiandola in modo abbastanza lineare e con pochi problemi.

Nel tentativo, infine, di testare la nuova implementazione con i test automatici, mi sono scontrato per l'ennesima volta col problema della configurazione dell'ambiente Dancer di riferimento. Ho cercato, cioè, di fare in modo che nel momento in cui viene eseguito un test automatico questo carichi un suo specifico yml di configurazione. Qualsiasi esempio trovato su internet ha fallito nel farmi fare una cosa del genere. Non mi rimane che lanciare il test con:

perl t/000X_test.t --environment=t

 Ora voglio, come cosa "facile" estendere il test perché il sistema arrivi alla vittoria e e poi come cosa "molto difficile" fare la stessa cosa di Element::User con Element::Game che però ha sicuramente molto più codice interessante...

[cym0n-blog]

Test suite

Mi sono divertito un po' con i test. Ho programmato una suite di test per DjakaWeb, da poter usare per verificare eventuali regressioni quantomeno nella navigazione principale. Ovviamente il problema principale è stato quello di aggirare la login via facebook. Fortunatamente già quando la avevo progettata in origine l'avevo dotata di uno stub. Mi è stato quindi sufficiente ripulire quello che già c'era e renderlo un po' più agile. Adesso posso far entrare nel sistema un non-utente facebook (facebook id fasulla) che viene accettato come un utente reale. Visto che tanto, post-login, non è che le interazioni col social network siano poi tante credo che questo dovrebbe essere sufficiente per avere un sistema consistente e di facile utilizzo. Ho progettato la suite in modo da simulare una navigazione standard dell'utente. Viene verificato l'accesso alla pagina principale, vengono fatte tutte le chiamate AJAX possibili nella pagina per popolare i vari box e infine viene selezionata un'azione. A questo punto ho inserito un paio di controlli per verificare che i click inibiti in questo stadio dell'interazione portino correttamente alle courtesy (trovando, tra parentesi, pure un vecchio bug) e infine ho anche simulato il meccanismo aspetta e clicca con uno sleep e l'invocazione della URL relativa. Tanto per essere pignolo, finite tutte le navigazioni, ho instanziato un paio di classi con i dati del mio utente di test e ci ho guardato dentro per verificare che contenessero tutto quello che mi aspettavo. Il giro totale, in conclusione, sono 18 test e hanno ragion d'essere, nel senso che effettivamente, se ci fosse un problema anche subdolo, potrebbero rilevarlo. La raffinatezza che mi manca e che vorrei introdurre è quella di usare un DB a sé, che viene svuotato all'inizio di ogni run, al posto dell'effettivo DB dell'ambiente di sviluppo. La cosa più semplice che mi viene in mente è creare un DB gemello e modificare lo schema della configurazione della suite di test. Peccato che debba tutt'oggi scoprire come modificare il config richiamato dalla suite stessa... L'unico rammarico che ho è che questa struttura mi sarebbe servita molto di più in passato che oggi. Le funzionalità base del sistema ormai sono abbastanza consolidate e non credo che nei prossimi sviluppi farò modifiche pericolose nei riguardi di queste cose. Ricordo invece dei momenti di robusto refactoring in cui questo script mi avrebbe fatto proprio comodo.

 Musica nelle orecchie: http://www.youtube.com/watch?v=m4cgLL8JaVI