ditemi voi che dovrei fare...

[71104]

ecco un perfetto esempio del perché ci siamo bloccati:

    public void testFlashGemDeleteFlashGem()
    {
        insertAndUpdate(createFlashingGem(), 13, 0);
        insertAndUpdate(createFlashingGem(), 12, 0);
        insertAndUpdate(createGem(DIAMOND), 11, 0);
        insertAndUpdate(createGem(DIAMOND), 13, 7);
        insertAndUpdate(createFlashingGem(), 13, 2);

        insertAndDropGemsPair();
        makeAllGemsFall();

        controller.update(environment.getTimer().getTime());

        assertNull(grid.getDroppableAt(13, 2));
        assertNull(grid.getDroppableAt(13, 0));
        assertEquals(grid.getDroppableAt(12, 0).getGridObject().getColor(), DIAMOND);
        assertEquals(grid.getDroppableAt(13, 7).getGridObject().getColor(), DIAMOND);
    }

mi vorreste spiegare che cavolo è sta porcheria? che fa? boh... ora mi trovo alle prese co sto coso che in seguito ad un mio refactoring non passa... e io secondo voi che dovrei fare? lo commento? ho già fatto praticamente una STRAGE di test commentati, io non lo so... -_-'

eh, ma qui ogni volta che il team viene richiamato all'attenzione scompaiono subito tutti e ci si blocca di nuovo... e grazie al !!
sapete che vi dico? lo commento e committo; tanto il progetto è ufficialmente chiuso, col codice possiamo farci tutto quello che vogliamo e il mio refactoring è sicuramente più utile di quel test criptico. "testFlashGemDeleteFlashGem", un nome un perché: ma per testare che una flash cancellasse un'altra flash, non bastava piazzare due flash una accanto all'altra, aggiornare e asserire? potevano essere quattro istruzioni, eh...

EDIT: a proposito, il test non passa, ma le flash cancellano ancora le flash; ditemi voi...

[71104]

ennò, neanche per sogno, perché il repository al momento non è up...

[jappilas]

...mi sa che c'è un po' di rumenta anche in testgameloop.java, ad es: le parti evidenziate di questi test, hanno senso in quel punto?

    public void testSelectVersusModeMenuItem() throws IOException
    {
        [.....]assertTrue("The GameLoop must be running", gameLoop.inGameLoop());
        
        //TODO usare il mapping di config
        //P1.DOWN -> KEY_S, P1.BLOW-> KEY_E
        Event event = Event.create(Event.Code.KEY_E, Event.State.PRESSED);
        gameLoop.getPlayerOneInput().notify(event);
        assertNull("The event blow must not generate a Event", gameLoop.getPlayerOneInput().extractEvent());
    }
    
    public void testSelectAdvancedModeMenuItem() throws IOException
    {
       [.....]assertTrue("The GameLoop must be running", gameLoop.inGameLoop());
        
        //TODO usare il mapping di config
        //P1.DOWN -> KEY_S, P1.BLOW-> KEY_E
        Event event = Event.create(Event.Code.KEY_E, Event.State.PRESSED);
        gameLoop.getPlayerOneInput().notify(event);
        assertNotNull("The event blow must not generate a Event", gameLoop.getPlayerOneInput().extractEvent());
    }

Originariamente inviato da 71104

ma per testare che una flash cancellasse un'altra flash, non bastava piazzare due flash una accanto all'altra, aggiornare e asserire? potevano essere quattro istruzioni, eh...

in teoria, direi di sì
[mind reading mode]
in pratica , probabilmente chi ha scritto quel test voleva accertarsi che la flash desse la priorità all' altra flash senza cancellare pure la gemma e senza scrivere un altro test ...
[/mind reading mode]

[71104]

bah, io sono fin troppo paziente: sono riuscito a committare senza commentare quel test; troppo paziente... -.-

[^TiGeRShArK^]

boh... non ho idea di cosa sia quel test... mai visto prima...
ma direi che una cosa assolutamente da fare è scrivere delle specie di "linee guida" x come testare certe cose...
ad esempio qualche volta mi è capitato di non sapere come fare un test perchè i test che facevano qualcosa simile erano completamente diversi l'uno con l'altro...
alla fine pensavo di aver capito come fare e invece...kazzi... non fungeva il test....
questo perchè con i vari refactoring mi sa che si è perso un pò "il filo" e ci sono test che usano ancora dei vecchi metodi per testare quando in realtà utilizzando i nuovi metodi aggiunti nelle varie classi sarebbero molto + semplici....

cmq... tenete duro fino a mercoledì ke finalmente potrò ricominiciare a lavorare su diamonds...
anzi... forse giovedì pure... dipende da quello ke sarà rimasto del mio cervello dopo aver studiato 8 miliardi di leggi diverse

EDIT: dimenticavo... soprattutto dovrebbe essere OBBLIGATORIO scrivere il messaggio nell'assert...altrimenti non si capisce una mazza di cosa faccia quel test...

[jappilas]

Originariamente inviato da ^TiGeRShArK^

cmq... tenete duro fino a mercoledì ke finalmente potrò ricominiciare a lavorare su diamonds...
anzi... forse giovedì pure... dipende da quello ke sarà rimasto del mio cervello dopo aver studiato 8 miliardi di leggi diverse

ciao danilo, noi ti si aspetta speranzosi
però ho l' impressione che quello che deve resistere e tenere duro sia tu... mi sa che uno studio pesante più di quello che stai facendo non ci sia...

EDIT: dimenticavo... soprattutto dovrebbe essere OBBLIGATORIO scrivere il messaggio nell'assert...altrimenti non si capisce una mazza di cosa faccia quel test...

mi pare fosse anche tra i dettami di fek o vicius di un po' di tempo fa, in effetti...

[^TiGeRShArK^]

Originariamente inviato da jappilas

ciao danilo, noi ti si aspetta speranzosi
però ho l' impressione che quello che deve resistere e tenere duro sia tu... mi sa che uno studio pesante più di quello che stai facendo non ci sia...

eh si lo so....
mi sono iscritto ad ingegneria per non aver NULLA a che fare con leggi et similia e ora mi ritrovo a studiare 'ste schifezze che al solo pensiero mi viene il ....
Spero solo di aver conservato un minimo di sanità mentale xkè in quest'anno mi sono letteralmente macinato il cervello e spero che siano rimasti giusto due o 3 neuroni per permettermi di riagganciarmi al team

e ora vado a letto ke sto scoppiando...

[Bonfo]

Già, i test

Non mi tiro fuori...anch'io a volte ho fatto porcate di test che la metà bastava.
Il problema è già venuto fuori varie volte:
http://www.hwupgrade.it/forum/showthread.php?t=1223385

Direi che i test sono da rifattorizzare tutti...e quello sarò un'altro lavoro da paura

[71104]

CHE INUMANA PORCHERIA... O_______O'''

    public void testCrushesCounters()
    {
        insertAndUpdate(createGem(EMERALD), 13, 2);
        insertAndUpdate(createGem(DIAMOND), 12, 2);
        insertAndUpdate(createChest(DIAMOND), 11, 2);
        insertAndUpdate(createChest(EMERALD), 10, 2);

        insertAndUpdate(createGem(RUBY), 9, 2);

        insertAndDropGemsPair();
        makeAllGemsFall();

        controller.update(environment.getTimer().getTime());

        checkCountersValues(grid, 5, 1, 1);

        makeAllGemsFall();

        environment.getTimer().advance(
            environment.getConfig().getInteger("DelayBetweenCrushes"));

        controller.update(environment.getTimer().getTime());

        checkCountersValues(grid, 3, 2, 2);

        makeAllGemsFall();

        environment.getTimer().advance(
            environment.getConfig().getInteger("DelayBetweenCrushes"));
        controller.update(environment.getTimer().getTime());

        insertAndUpdate(createGem(DIAMOND), 13, 1);
        insertAndUpdate(createChest(DIAMOND), 12, 1);

        insertAndUpdate(createGem(RUBY), 11, 1);

        environment.getTimer().advance(
            environment.getConfig().getInteger("NewGemDelay"));
        controller.update(environment.getTimer().getTime());

        makeAllGemsFall();
        controller.update(environment.getTimer().getTime());

        checkCountersValues(grid, 6, 1, 1);
    }

ma a che razza di livello è testato il codice implicato in quell'affare, qualunque esso sia...? :|

ma come può Diamond Crush contenere una cosa simile? :|

Bonfo, diciamo pure che sono da refattorizzare solo per metà: l'altra metà è da rifare -.-

[71104]

secondo me test come quello che ho appena sgamato e che ho quotato qui sopra sono nati in quel periodo che cercavamo di riprodurre situazioni varie per le big gems; quel test credo che cerci di riprodurre qualche assurdissima situazione in cui avevamo un bug... ma non è così che si deve fare: in queste situazioni trovare le condizioni che riproducono il bug è solo il primo passo: successivamente bisogna capire la causa del bug, ovvero quale linea di codice esattamente manca per evitarlo (o quale linea di troppo va cancellata); nel caso si debba aggiungere una linea, questa va testata nella maniera più semplice, stretta e diretta possibile, mentre nel caso se ne debba togliere una allora va rimosso anche il test che richiede la sua presenza.

[cdimauro]

I test non sono necessariamente legati a un bug: molto spesso rappresentano la "formalizzazione" dei requisiti richiesti (dal customer).

Comunque sono d'accordo: è un test enorme, e aggiungo che un nome più esplicativo sarebbe stato meglio.

[thebol]

è un test che deve simulare 2 crush(con il chainCounter che cresce), e poi un altro dopo aver inserito la gemsPair(il chainCounter deve essersi resettato).

i tanti check, sono stati usati per verificare l'evolversi dei contatori.

Ho a volte trovato dei test che passavano perche testavano la condizione sbagliata, o cose simili. Per questo spesso uso piu assert, per dimostrare che prima la situazione è in un modo, e poi in un altro.(classico esempio andare a vedere se nella posizione x,y non ci deve essere la gemma, si sbagliano le coordinate e il test passa per sbaglio..)


Sicuramente si poteva fare il tutto in 2 test, ho fatto cosi, perche nel secondo avrei dovuto replicare quasi tutto il codice del primo per arrivare ad avere il chainCrush a 2(non avendo accesso al setter..)

[Bonfo]

Originariamente inviato da thebol

è un test che deve simulare 2 crush(con il chainCounter che cresce), e poi un altro dopo aver inserito la gemsPair(il chainCounter deve essersi resettato).

i tanti check, sono stati usati per verificare l'evolversi dei contatori.

Ho a volte trovato dei test che passavano perche testavano la condizione sbagliata, o cose simili. Per questo spesso uso piu assert, per dimostrare che prima la situazione è in un modo, e poi in un altro.(classico esempio andare a vedere se nella posizione x,y non ci deve essere la gemma, si sbagliano le coordinate e il test passa per sbaglio..)


Sicuramente si poteva fare il tutto in 2 test, ho fatto cosi, perche nel secondo avrei dovuto replicare quasi tutto il codice del primo per arrivare ad avere il chainCrush a 2(non avendo accesso al setter..)

Capita spesso ... ecco perchè bisogna fare refactoring anche dei test e usare gli extract method anche nei test.
Io sono il primo che se lo scorda e preferisce la soluzione che hai usato tu. Ma se non ci abituiamo inmodo diversoil gioco si fa duro.

[thebol]

Originariamente inviato da Bonfo

Capita spesso ... ecco perchè bisogna fare refactoring anche dei test e usare gli extract method anche nei test.
Io sono il primo che se lo scorda e preferisce la soluzione che hai usato tu. Ma se non ci abituiamo inmodo diversoil gioco si fa duro.

in effetti servirebbero dei metodi helper per lavorare sulla griglia(alla makeAllGemFAll()....)

[cdimauro]

Basterebbe spostare tanti metodi utili in un BaseTest, e far discendere i test da questa classe.

[thebol]

Originariamente inviato da cdimauro

Basterebbe spostare tanti metodi utili in un BaseTest, e far discendere i test da questa classe.

Vero, ma ci sono dei metodi facilmente generalizzabili(makeallgemFall).

Altri meno..perche devono essere fatti in modo da lasciare pulita la griglia(senza o con la gemsPair?), e devono lasciare la griglia in uno stato ben definito(sempre lo stesso?), in modo che chi le usi dopo sappia cosa fare.

Altrimenti, si sposta solo il problema..

[Bonfo]

Originariamente inviato da thebol

Vero, ma ci sono dei metodi facilmente generalizzabili(makeallgemFall).

Altri meno..perche devono essere fatti in modo da lasciare pulita la griglia(senza o con la gemsPair?), e devono lasciare la griglia in uno stato ben definito(sempre lo stesso?), in modo che chi le usi dopo sappia cosa fare.

Altrimenti, si sposta solo il problema..

Per me bisogna arrivare ad avere una classe di Utility per operare sulla griglia.
Ovvero nel costruttore della GridTestUtility si passa la griglia e dopo la si può settare come si pare (presenza o meno della gemsPair) ed effettuare tutte le operazioni "general-purpose"

[71104]

Originariamente inviato da thebol

i tanti check, sono stati usati per verificare l'evolversi dei contatori.

ennò, non ci siamo... se fai così vuol dire che stai testando più d'una funzionalità del programma; ogni test deve testare una sola funzionalità e lo deve fare nella maniera più diretta possibile; il TDD in forma pura (quello che faccio sempre io ) prevede un test per ogni riga di codice, contando ovviamente solo le righe significative (non serve testare le parentesi graffe e le righe vuote insomma )

Ho a volte trovato dei test che passavano perche testavano la condizione sbagliata, o cose simili. Per questo spesso uso piu assert, per dimostrare che prima la situazione è in un modo, e poi in un altro.(classico esempio andare a vedere se nella posizione x,y non ci deve essere la gemma, si sbagliano le coordinate e il test passa per sbaglio..)

e come mai usare più asserzioni risolverebbe la cosa...? quando scrivi i test tu non puoi partire dal presupposto che tu potresti sbagliare a scrivere il test stesso oltre al codice. a parte che non è bene scrivere numeri costanti nel codice e una delle prossime cose da fare (dopo il sistema di log, che è più urgente) sarà sostituirli tutti con costanti e formule che operano sulle costanti, ma comunque anche se sbagli a scrivere un test e questo passa i casi sono due:
1) fallisce il corrispettivo "contro-test", ovvero il test che verifica che il codice testato non solo funzioni in un certo modo, ma che non funzioni in nessun altro modo
2) a runtime ti accorgi tu stesso che il programma non funziona

Sicuramente si poteva fare il tutto in 2 test

le righe di codice testate da quel test sono solo 2 escludendo parentesi graffe e righe vuote?

[thebol]

Originariamente inviato da 71104

1) fallisce il corrispettivo "contro-test", ovvero il test che verifica che il codice testato non solo funzioni in un certo modo, ma che non funzioni in nessun altro modo

raramente fattibile.

2) a runtime ti accorgi tu stesso che il programma non funziona

togliamo i test allora? che discorso è?

le righe di codice testate da quel test sono solo 2 escludendo parentesi graffe e righe vuote?

non sempre si testano oggetti "finali". A volte si testano entita di livello un po piu alto(da gridController, a playField per esempio), e se ne testa il comportamento(magari poi realizzato da un oggetto), percui il discorso una riga un test, non è un dogma.

[71104]

Originariamente inviato da thebol

raramente fattibile.

così raramente che io lo faccio sempre. EDIT: quasi sempre
più fattibile di quello che pensi comunque

togliamo i test allora? che discorso è?

non è quello l'unico vantaggio dell'usare i test

non sempre si testano oggetti "finali". A volte si testano entita di livello un po piu alto(da gridController, a playField per esempio), e se ne testa il comportamento(magari poi realizzato da un oggetto), percui il discorso una riga un test, non è un dogma.

mock