[CICLO 1] Abbiamo il primo bug!

[fek]

Non e' proprio un bug, ma vediamo come reagirebbe il Customer al task che richiede l'input della tastiera.
Il Customer lancia l'applicazione, preme un tasto freccia e vede il diamante che si muove. Yay! Preme un altro tasto freccia e vede il diamante muoversi in un'altra direzione. Yay! Poi preme due tasti freccia contemporaneamente, vorrebbe vedere il diamante muoversi in diagonale, ma il nostro gioco registra solo l'ultimo tasto premuto. Sguardo perplesso del customer che pensa: "C'e' un bug".

In realta' no, le sue specifiche non richiedevano questo comportamento ed erano piuttosto vaghe in merito, c'era spazio per l'interpretazione, che per caso non era quello che il Customer pensava.

Comunque sia ora il Customer ha le idee piu' chiare, e qui si puo' vedere il valore dell'avere un processo di sviluppo che ogni due settimane consegna qualcosa di usabile al Customer: il Customer puo' chiarirsi le idee usando l'applicazione e puo' chiarirle al team di sviluppo che puo' velocemente correggere i problemi.

Ora il Customer ha le idee piu' chiare: "Quando premo due tasti freccia (ad esempo alto e destra) in contemporanea, vorrei che il diamante si muovesse in diagonale".

La palla passa a noi per correggere il bug, guardiamo il codice, si' il problema forse e' li', lo correggiamo e noooooooo!

Prima di correggere un qualunque bug si scrive un test che fallisce in presenza della condizione che genera il bug.

Si lancia il test e si verifica che fallice, poi si corregge il bug, si lancia il test di nuovo e si verifica che non fallisce piu'. Il bug e' risolto, abbiamo un modo automatico per verificarlo e sappiamo che, se in futuro cambieremo il codice da qualche parte e introducessimo il bug nuovamente, il test ci avvertira' subito facendoci risparmiare tempo.

La logica dietro a questa regola e' che un bug non e' altro che il verificarsi di una condizione indesiderata e nella nostra rete di test non ce n'e' uno che fallisca al verificarsi di quella condizione, avvertendoci della presenza del bug. La nostra rete di test non e' abbastanza fitta ed un bug e' passato. Bisogna renderla piu' fitta e assicurarsi che questo bug non passi piu' inosservato.

Ora, guardate la classe KeyboardImpl e suggeritemi qualche test che possa rilevare la condizione di due tasti premuti contemporaneamente e solo l'ultimo e' registrato.

[VICIUS]

Diagonale e ritorno verso l'alto in un gioco a-la tetris

ciao

[fek]

Originariamente inviato da VICIUS

Diagonale e ritorno verso l'alto in un gioco a-la tetris

ciao

Sai come sono i Customer, non hanno mai le idee chiare

(in realta' ho solo sfruttato la scusa per introdurre il discorso sui bug e i test )

[VICIUS]

Originariamente inviato da fek

Sai come sono i Customer, non hanno mai le idee chiare

(in realta' ho solo sfruttato la scusa per introdurre il discorso sui bug e i test )

eheh ora è tutto piu chiaro.

ciao

[cionci]

Domanda, ma è un bug ? A quanto pare la classe KeyboardImpl gestisce anche la possibilità di più tasti premuti contemporaneamente, imho questa potrebbe essere semplicemente una feature non ancora implementata dal codice (visto che non è stata richiesta)...

Ad esempio per implementarla basterebbe un refactoring alla classe input... Oltre a richiedere alla classe input lo stato dei tasti possiamo richiedergli anche la direzione scelta... Ad esempio con metodi di questo tipo:

public Boolean isLeftDirection()
{
return isKeyLeft() && !isKeyRight() && !isKeyLeft() && !isKeyUp();
}

[fek]

Tecnicamente il "bug" e' nell'uso che la classe Game fa della classe Keyboard.

Ne abbiamo parlato io e Cesare, il problema della classe Keyboard e' che al momento molto del suo comportamento non e' di fatto testato, quindi vogliamo modificarla di modo da essere piu' facilmente testabile.

Una volta che abbiamo abbastanza confidenza nella classe test, possiamo cambiare il codice in Game e correggere il "bug".

[fek]

Cesare e' giunto a definire il codice del test che non passa e che vogliamo che passi per risolvere il bug:

keyboard.generateKeyPressEvent(left); 
keyboard.generateKeyPressEvent(right); 

assertTrue(input.isLeftPressed()); 
assertTrue(input.isRightPressed()); 
 
keyboard.generateKeyReleaseEvent(right); 

assertFalse(input.isRightPressed());
assertTrue(input.isLeftPressed());

Ora non resta che scrivere il codice che fa passare questo test (e tutti gl'altri).

[Jocchan]

Originariamente inviato da fek

Sai come sono i Customer, non hanno mai le idee chiare

(in realta' ho solo sfruttato la scusa per introdurre il discorso sui bug e i test )

Ma io ho le idee chiare

[fek]

Originariamente inviato da Jocchan

Ma io ho le idee chiare

E invece no!

Ti sei accorto che premendo prima la freccia a destra e poi la freccia a sinistra contemporaneamente il diamante si sposta a destra, mentre vuoi che stia fermo. Bug!

Da correggere, ma non prima di un bel test che lo esponga

come? Mi dici che non te n'eri accorto? Dettagli implementatitivi...

[cdimauro]

Diabolico...

[fek]

cisc, ho visto che hai corretto un bug.
Scritto anche il test che lo espone?

Me lo posti qui per favore?

[cisc]

ecco il test, messo in testSprite.java:

public void testCollision() 

    {

        sprite.move(-100,0);

        assertEquals(texture.getWidth()/2, sprite.getX(), 0.001f);

        assertEquals(200, sprite.getY(), 0.001f);

        sprite.move(0,10);

        assertEquals(210, sprite.getY(), 0.001f);

        

        

    }

uso texture.getWidth() perchè in setup ho messo sprite.setSizeX(texture.getWidth()); , questo magari è una cosa che si può modificare...

[fek]

Ottimo!

Una volta che abbiamo il test possiamo modificare quello che ci pare

[cisc]

mi sa che ho trovato un altro bug, se è avvenuta una collisione e scorro sulla parete fino ad arrivare ad un'altra collisione sulla parete ortogonale, non si sente il suono...cmq il bug di prima è stato trovato da DanieleC88

[VICIUS]

Originariamente inviato da cisc

mi sa che ho trovato un altro bug, se è avvenuta una collisione e scorro sulla parete fino ad arrivare ad un'altra collisione sulla parete ortogonale, non si sente il suono...cmq il bug di prima è stato trovato da DanieleC88

Vero. Test e poi fix

ciao

[cionci]

C'è un'altro bug...anche se credo che sia difficile da testare... In pratica avvicinando il più lentamente possibile al bordo il suono viene eseguito tante volte (provate diverse volte, non è facile arrivare nella posizione giusta)...
Probabilmente il bug sia ha quando con un movimento si arriva al bordo precisi al pixel...

[cionci]

Il problema è qui (o almeno dove si verifica)...la correzione andrà fatta nell'algoritmo di collisione che dovrà chiamare stopPulse...

moved è falso, mentre isPulsing ritorna vero:

    public boolean move(float dx, float dy)
    {
        boolean moved = super.move(dx, dy);

        if(moved)
        {
            if(!isPulsing())
            {
                startPulse();
            }
        }
        else
        {
            if(isPulsing())
            {
                stopPulse();
                /* TODO: manage double collision
                 * between two orthogonal walls and
                 * play sound on second collision
                 */
                if (collisionSound != null)
                {
                    collisionSound.play();
                }
            }
        }

        return moved;
    }

[cionci]

Il problema è ancora più strano... Mettendo un breakpoint nella playSound si raggiunge il break point non tute le volte che si la move di Gem, ma una volta sì ed una volta no (quindi la prima volta viene fermato il pulse, la seconda viene ristabilito)... Veramente strano... Indago meglio...

[cionci]

Non ne sto venendo a capo... Ora il suono viene suonato una volta sì e N no... Probabilmente p una situazione diversa di errore...

[cisc]

cionci a quanto ho capito il problema è che quando ti avvicini in un certo modo, il diamante sta pulsando e quindi, dato che il codice delle collisioni controlla valori che in realtà stanno variando, si crea questo bug, penso che la soluzione più semplice sia nel mantenere altre due variabili che memorizzino le dimensioni "statiche" del diamante, l'unico problema che sto avendo è il fare un test che mi rilevi il bug..