To test or not to test

cdimauro · 30-03-2006, 09:51

Lavorando al porting di Diamonds per le librerie SDL, dopo aver finito con tutta la parte relativo al sonoro (Audio, Sound, e annessi), ho lanciato al solito Ant per controllare se la build era a posto, e ho trovato un'amara sorpresa:

Codice:

    [junit] Testcase: testPlayFieldAttached(it.diamonds.tests.TestGame):	Caused an ERROR
    [junit] i can not find the sound file 'data/diamond.wav'
    [junit] it.diamonds.engine.audio.SoundException: i can not find the sound file 'data/diamond.wav'
    [junit] at it.diamonds.engine.audio.Sound.readSoundFile(Sound.java:99)
    [junit] at it.diamonds.engine.audio.Sound.<init>(Sound.java:33)
    [junit] at it.diamonds.engine.audio.Sound.<init>(Sound.java:23)
    [junit] at it.diamonds.gems.GemFactory.<init>(GemFactory.java:34)
    [junit] at it.diamonds.gems.GemQueue.<init>(GemQueue.java:24)
    [junit] at it.diamonds.GridController.create(GridController.java:340)
    [junit] at it.diamonds.PlayField.<init>(PlayField.java:69)
    [junit] at it.diamonds.GameLoop.createPlayField(GameLoop.java:306)
    [junit] at it.diamonds.GameLoop.createPlayFieldOne(GameLoop.java:318)
    [junit] at it.diamonds.Bootstrap.setUpPlayFields(Bootstrap.java:51)
    [junit] at it.diamonds.Bootstrap.setUpGameForTesting(Bootstrap.java:113)
    [junit] at it.diamonds.Game.createGameForTesting(Game.java:123)
    [junit] at it.diamonds.tests.TestGame.testPlayFieldAttached(TestGame.java:12)

BUILD FAILED
C:\Documents and Settings\Cesare\workspace\Diamonds\build.xml:99: Test it.diamonds.tests.TestGame failed

Al di là del fatto che il file non venga trovato (ci sto lavorando per capire qual è il problema), mi chiedo: che senso ha avere roba come
public static Sound createForTesting(String fileName)
quando poi a partire da Bootstrap.setUpPlayFields() l'informazione che stiamo lavorando su un ambiente di test e non su uno "in produzione" viene del tutto persa?

A catena, fino ad arrivare a Sound, non sarebbe stato necessario chiamare i vari metodi "createForTesting"?

P.S. Sto cambiando, dove trovo, l'accesso ai dati, perché attualmente si usa il separatore "/" che è "hard coded", anziché java.io.File.separator (ad esempio, in Sound, al posto di soundDir = "data/" ho messo soundDir = "data" + java.io.File.separator; ).

cdimauro · 30-03-2006, 10:05

Modificando readSoundFile(String fileName) in modo da fargli restituire anche il messaggio d'errore dell'eccezione generata (prima sollevava soltanto SoundException col messaggio che il file non era stato trovato), si capisce qual è il problema:

Codice:

    [junit] i can not find the sound file 'data\diamond.wav' Error:sdljava.SDLException: Audio device hasn't been opened
    [junit] it.diamonds.engine.audio.SoundException: i can not find the sound file 'data\diamond.wav' Error:sdljava.SDLException: Audio device hasn't been opened

Il che conferma quanto scritto in precedenza.

Ufo13 · 30-03-2006, 10:57

ottimo

riguardo i createForTesting secondo me è meglio che inserire un null come audio

cdimauro · 30-03-2006, 11:23

Finalmente la build è verde, ma è stato un bagno di sangue: ho dovuto modificare una notevole quantità di test per fargli creare Audio (e ho cambiato anche i posti in cui c'era un setAudio(null)), in modo che, alla creazione di Sound, l'audio fosse già aperto e inizializzato.

Quella di cambiare i test è una soluzione che non mi piace assolutamente, ma per adesso è quella più veloce.
In futuro sarà necessario ripensare i test e far sì che l'informazione che indica che si sta lavorando in un ambiente di test venga propagata correttamente a TUTTI i livelli del codice.

Altra cosa importante, in questo senso, è che forse è meglio che TUTTI i test ereditino da un qualche test base E che richiamino almeno il suo metodo setUp (purtroppo ho trovato diversi test che non lo facevano.

), in modo da rendere più facile l'introduzione di azioni di inizializzazione "generali".

Spero che per la gestione della tastiera, che è l'ultima cosa che m'è rimasta da fare, non presenti problemi nella stessa misura.

cdimauro · 30-03-2006, 11:24

Quote:

Originariamente inviato da Ufo13

ottimo

riguardo i createForTesting secondo me è meglio che inserire un null come audio

Concordo.

fek · 30-03-2006, 13:37

Quote:

Originariamente inviato da cdimauro

Finalmente la build è verde, ma è stato un bagno di sangue: ho dovuto modificare una notevole quantità di test per fargli creare Audio (e ho cambiato anche i posti in cui c'era un setAudio(null)), in modo che, alla creazione di Sound, l'audio fosse già aperto e inizializzato.

Quella di cambiare i test è una soluzione che non mi piace assolutamente, ma per adesso è quella più veloce.
In futuro sarà necessario ripensare i test e far sì che l'informazione che indica che si sta lavorando in un ambiente di test venga propagata correttamente a TUTTI i livelli del codice.

Altra cosa importante, in questo senso, è che forse è meglio che TUTTI i test ereditino da un qualche test base E che richiamino almeno il suo metodo setUp (purtroppo ho trovato diversi test che non lo facevano.

), in modo da rendere più facile l'introduzione di azioni di inizializzazione "generali".

Spero che per la gestione della tastiera, che è l'ultima cosa che m'è rimasta da fare, non presenti problemi nella stessa misura.

Io mockerei la classe Audio con una classe NullAudio (o similare). Sound vedrebbe questa classe NullAudio nei test che non fa nulla. Dovrebbe notevolmente semplificare l'implementazione dei test. Nel finesettimana gli butto uno sguardo.

cdimauro · 30-03-2006, 13:49

Purtroppo non penso che potrebbe andare. A Sound non interessa niente di Audio: neppure interagisce con questa classe e nemmeno conosce / usa una sua istanza.

Il "legame" fra Sound e Audio è rappresentato in questo momento (nel mio codice SDL) soltanto da SDLMixer, che è la classe che si occupa di far partire l'engine audio avanzato (non uso quello "di base" della SDL) e permette di caricare e suonare in maniera molto semplice e veloce file wav (gestendo una marea di altre cose, ma per il momento non me ne frega niente: voglio soltanto far partire Diamonds).

Il problema da me sollevato nasce dal fatto che in alcuni test viene creata un'istanza di Sound, usando il suo costruttore "normale" anziché usare Sound.createForTesting() (che abilita la "simulazione" del caricamento, esecuzione e stop di un suono).

Così facendo, Sound prova a caricare un suono usando un'API di SDLMixer, ma poiché l'engine audio non è inizializzato (questo è un "compito" di Audio, appunto), fallisce (l'audio engine inizializzato è un prerequisito per usare SDLMixer).

Con LWJGL questo non succedeva, forse perché le API relative al caricamento di un suono funzionavano lo stesso.

Il comportamento scorretto non è di Sound (almeno credo), quanto dei test che dovrebbero richiamare a tutti livelli le rispettive createForTesting.

fek · 30-03-2006, 13:53

Quote:

Originariamente inviato da cdimauro

Il comportamento scorretto non è di Sound (almeno credo), quanto dei test che dovrebbero richiamare a tutti livelli le rispettive createForTesting.

Capito, hai ragione. Allora la soluzione non e' inizializzare l'Audio (altrimenti la build machine fallisce), ma assicurarsi che Sound sia sempre creato con createForTesting.

cdimauro · 30-03-2006, 13:58

Esattamente. Ma ci vuol un po' di lavoro, e francamente in questo momento non ho molto tempo (il porting con SDL me ne porta via già parecchio).

Comunque penso che con le SDL la build machine potrebbe anche fare a meno di alcuni mock, o per lo meno limitarli molto, in quanto molte API funzionano lo stesso anche senza che la rispettiva sezione sia in esecuzione (es: inizializzo la sottosezione video e posso caricare texture / immagini, anche se non ho aperto nessuno schermo; idem per l'audio).

Bonfo · 30-03-2006, 14:43

Quote:

In futuro sarà necessario ripensare i test e far sì che l'informazione che indica che si sta lavorando in un ambiente di test venga propagata correttamente a TUTTI i livelli del codice.

Secondo me qua si sta sbagliando qualcosa.
i test che stiamo facendo non sono semplicemente UnitTest.
Ci sono test che controllano che classi "suiperiori" usino correttamente classi "inferiori".

Esempio (non penso sia reale):
test che controlla che Game inizializzi corettamente i PlayField.
Il test deve controlare che il VERO Game inizzializzi correttamente i VERI PlayField.
Cosa ce ne facciamo che dentro il codice di game si controlli che siano usati correttamente i PlayField dio test???

Ci saranno sempre dei test cha al loro interno utilizzano classi VERI...è necessario per la coretta implementazione.
Spero di esseremi spiegato

cdimauro · 30-03-2006, 17:42

In tal caso si dovrebbe avere l'accortezza di inizializzare, ad esempio, l'audio, prima di creare un'istanza di Sound che importa un file.

30-03-2006, 10:05	#2
cdimauro Senior Member Iscritto dal: Jan 2002 Città: Germania Messaggi: 26110	Modificando readSoundFile(String fileName) in modo da fargli restituire anche il messaggio d'errore dell'eccezione generata (prima sollevava soltanto SoundException col messaggio che il file non era stato trovato), si capisce qual è il problema: Codice: [junit] i can not find the sound file 'data\diamond.wav' Error:sdljava.SDLException: Audio device hasn't been opened [junit] it.diamonds.engine.audio.SoundException: i can not find the sound file 'data\diamond.wav' Error:sdljava.SDLException: Audio device hasn't been opened Il che conferma quanto scritto in precedenza.

30-03-2006, 10:57	#3
Ufo13 Senior Member Iscritto dal: Nov 2005 Messaggi: 1545	ottimo riguardo i createForTesting secondo me è meglio che inserire un null come audio

30-03-2006, 11:23	#4
cdimauro Senior Member Iscritto dal: Jan 2002 Città: Germania Messaggi: 26110	Finalmente la build è verde, ma è stato un bagno di sangue: ho dovuto modificare una notevole quantità di test per fargli creare Audio (e ho cambiato anche i posti in cui c'era un setAudio(null)), in modo che, alla creazione di Sound, l'audio fosse già aperto e inizializzato. Quella di cambiare i test è una soluzione che non mi piace assolutamente, ma per adesso è quella più veloce. In futuro sarà necessario ripensare i test e far sì che l'informazione che indica che si sta lavorando in un ambiente di test venga propagata correttamente a TUTTI i livelli del codice. Altra cosa importante, in questo senso, è che forse è meglio che TUTTI i test ereditino da un qualche test base E che richiamino almeno il suo metodo setUp (purtroppo ho trovato diversi test che non lo facevano. ), in modo da rendere più facile l'introduzione di azioni di inizializzazione "generali". Spero che per la gestione della tastiera, che è l'ultima cosa che m'è rimasta da fare, non presenti problemi nella stessa misura.

30-03-2006, 13:49	#7
cdimauro Senior Member Iscritto dal: Jan 2002 Città: Germania Messaggi: 26110	Purtroppo non penso che potrebbe andare. A Sound non interessa niente di Audio: neppure interagisce con questa classe e nemmeno conosce / usa una sua istanza. Il "legame" fra Sound e Audio è rappresentato in questo momento (nel mio codice SDL) soltanto da SDLMixer, che è la classe che si occupa di far partire l'engine audio avanzato (non uso quello "di base" della SDL) e permette di caricare e suonare in maniera molto semplice e veloce file wav (gestendo una marea di altre cose, ma per il momento non me ne frega niente: voglio soltanto far partire Diamonds). Il problema da me sollevato nasce dal fatto che in alcuni test viene creata un'istanza di Sound, usando il suo costruttore "normale" anziché usare Sound.createForTesting() (che abilita la "simulazione" del caricamento, esecuzione e stop di un suono). Così facendo, Sound prova a caricare un suono usando un'API di SDLMixer, ma poiché l'engine audio non è inizializzato (questo è un "compito" di Audio, appunto), fallisce (l'audio engine inizializzato è un prerequisito per usare SDLMixer). Con LWJGL questo non succedeva, forse perché le API relative al caricamento di un suono funzionavano lo stesso. Il comportamento scorretto non è di Sound (almeno credo), quanto dei test che dovrebbero richiamare a tutti livelli le rispettive createForTesting.

30-03-2006, 13:58	#9
cdimauro Senior Member Iscritto dal: Jan 2002 Città: Germania Messaggi: 26110	Esattamente. Ma ci vuol un po' di lavoro, e francamente in questo momento non ho molto tempo (il porting con SDL me ne porta via già parecchio). Comunque penso che con le SDL la build machine potrebbe anche fare a meno di alcuni mock, o per lo meno limitarli molto, in quanto molte API funzionano lo stesso anche senza che la rispettiva sezione sia in esecuzione (es: inizializzo la sottosezione video e posso caricare texture / immagini, anche se non ho aperto nessuno schermo; idem per l'audio).

30-03-2006, 17:42	#11
cdimauro Senior Member Iscritto dal: Jan 2002 Città: Germania Messaggi: 26110	In tal caso si dovrebbe avere l'accortezza di inizializzare, ad esempio, l'audio, prima di creare un'istanza di Sound che importa un file.

Strumenti
Mostra una versione stampabile Invia questa pagina per email