SpriteAnimation

[Ufo13]

Edit: ma porca miseria volevo scrivere AnimatedSprite :\

Ho dato insieme a Fran una lunga serie di botte alle animazioni fino ad ottenere una classe piuttosto stand-alone per la gestione delle animazioni.

I test, al momento, sono quasi tutti copiati (e rivisti) da TestGemAnimation.

TODO:

• Un paio di test vanno spostati da TestGemAnimation a TestAnimation.
• Capire/definire cosa fa un'oggetto AnimatedSprite.
• Completare/ripulire i test, soprattutto quelli che testano il rendering e la gestione delle sprite "bright"

Un sacco di inesattezze erano presenti nel codice che gestiva le animazioni in Droppable.
Prima di tutto era possibile creare animazioni contenenti 0 frame.
Ho aggiunto un test per impedire le animazioni lunghe 0 frame. Ora sto seriamente pensando di impedire pure la creazione di animazioni lunghe 1 frame (non ha senso). Cosa ne pensate?

Domanda aggiuntiva: possiamo fulminare il codice per gestire le bright sprite? A mio parere questa feature inutilizzata sporca il codice e basta...

[Bonfo]

Cancella, cancella

Comunque di schifezze ce ne sono un bel po' in giro. Pensa che puoi disegnare la grid con la texture del background che i test non si arrabbiano


Ovviamente ci sto lavorando per recuperare

[71104]

Originariamente inviato da Ufo13

Domanda aggiuntiva: possiamo fulminare il codice per gestire le bright sprite? A mio parere questa feature inutilizzata sporca il codice e basta...

quoto: c'ero passato pure io qualche giorno fa, refattorizzando a destra e a manca, e vedere tutto quel codice inutile mi dava fastidio. chiederei a fek un commit di tregua dai REFACTOR THIS solo per eliminare il codice del "brighter".

[71104]

Originariamente inviato da Bonfo

Pensa che puoi disegnare la grid con la texture del background che i test non si arrabbiano


Ovviamente ci sto lavorando per recuperare

non credo valga la pena di inserire nel codice tutti i test possibili ed immaginabili: sarebbero miliardi ^^, anche perché una stessa feature può essere testata a livelli diversi. più test mettiamo più ne dobbiamo mantenere (e questi bastardi in manutenzione si fanno decisamente sentire -.-), quindi io mi atterrei esclusivamente a test "stretti" che su ciascun metodo pubblico di una classe testino l'intero dominio (o la parte più larga possibile) verificandone il "codominio".

[Bonfo]

Originariamente inviato da 71104

non credo valga la pena di inserire nel codice tutti i test possibili ed immaginabili: sarebbero miliardi ^^, anche perché una stessa feature può essere testata a livelli diversi. più test mettiamo più ne dobbiamo mantenere (e questi bastardi in manutenzione si fanno decisamente sentire -.-), quindi io mi atterrei esclusivamente a test "stretti" che su ciascun metodo pubblico di una classe testino l'intero dominio (o la parte più larga possibile) verificandone il "codominio".

Non sono d'accordo. I test non sono manutenibili in questo momento perchè abbiamo sbagliati a farli. Non per nulla abbiamo test da 30 righe. Un test, se scritto bene, rimane li in eterno INVARIATO, perchè lui continua a testare sempre e solo quel singolo comportamento.

E' vero che una cosa può essere testata a tanti livelli, ma è sbagliato.
Sai quanti test "ugali" abbiamo in 10.000 testcase diversi?? Sai quante features sono testate un po qua e un po' la??
I test adesso sono un casino perchè li abbiamo sempre messi in secondo piano rispetto al codice del gioco.
Stupitevi, ma è l'esatto contrario. La cosa più importante è il codice dei test. Con una test-base "perfetta", anche mille scimme che picchiano a caso i tasti alla fine riuscirebbero a fare il gioco.

In ogni caso tutti qui test, se le cose fossero state sviluppate completamente e veramente in TDD, sarebbero tutti li.

Ieri ho rimesso a posto la classe Rectangle e il test sull'equals era sbagliato!!
Potevo benissimo togliere un paio di condizioni e il test passava lo stesso.
I test sono la nostra rete di salvataggio, definiscono come si comporta il sistema in ogni singolo aspetto... non esisterebbero bug se i test fossero fatti bene, o meglio, esisterebbero solo condizioni a cui gli sviluppatori e il costumer stesso non avevano pensato.

Scusate lo sfogo... ma in giro per i test vedo delle cose che

[Ufo13]

Purtroppo ha ragione Bonfo: abbiamo sbagliato noi. I test andavano mantenuti costantemente mentre noi siamo andati avanti a cicli pieni di nuove feature scrivendo test hackerini giusto per poter dire "l'ho fatto in TDD io!".

I test piu` disastrati sono gli integration test. Tipo quelli che testano che la griglia abbia effettivamente fatto update delle animazioni (per dirne una) oppure che la griglia dopo una update abbia effettivamente fatto merge di due BigGem etc etc...

In questo caso non sono ancora sicuro su come procedere ma forse con un paio di classi mock in piu` si sarebbero risolti parecchi problemi..

Inoltre le classi mock che abbiamo (tipo Engine) potrebbero essere migliorate

[fek]

Originariamente inviato da 71104

quoto: c'ero passato pure io qualche giorno fa, refattorizzando a destra e a manca, e vedere tutto quel codice inutile mi dava fastidio. chiederei a fek un commit di tregua dai REFACTOR THIS solo per eliminare il codice del "brighter".

No, un Refactor This per ogni commit. Se iniziamo a chiedere deroga senza aver neppure iniziato non ha molto senso. Ovviamente la soluzione non e' non fare il commit

Fede, a me un'animazione con un solo frame non crea problemi.

[fek]

Originariamente inviato da 71104

non credo valga la pena di inserire nel codice tutti i test possibili ed immaginabili: sarebbero miliardi ^^, anche perché una stessa feature può essere testata a livelli diversi. più test mettiamo più ne dobbiamo mantenere (e questi bastardi in manutenzione si fanno decisamente sentire -.-), quindi io mi atterrei esclusivamente a test "stretti" che su ciascun metodo pubblico di una classe testino l'intero dominio (o la parte più larga possibile) verificandone il "codominio".

Questo e' uno dei problemi della nostra batteria di test, problema che ho incontrato ieri: i test sono troppo pochi e a livello troppo alto. Facendo un piccolo cambiamento in BigGem mi sono ritrovato 10 test da 30 righe l'uno che fallivano. Ovviamente non avevo la piu' pallida idea del perche' fallissero, perche' erano a livello troppo alto.
Abbiamo bisogno di piu' test a livello piu' basso, che testano un solo piccolo comportamento in maniera chiara e inequivocabile di modo che un cambiamento nel codice che lo riguarda lo faccia fallire e il test indichi in maniera chiara il perche' del suo fallimento.

Al momento questo e' il nostro grosso limite che rende il lavoro di refactoring Diamonds poco piacevole, molto stressante e molto complesso.

[Ufo13]

Originariamente inviato da fek

No, un Refactor This per ogni commit. Se iniziamo a chiedere deroga senza aver neppure iniziato non ha molto senso. Ovviamente la soluzione non e' non fare il commit

Fede, a me un'animazione con un solo frame non crea problemi.

Ma che senso ha? Semplificherebbe un po' di test...

Non e` manco testabile poiche` il frame non cambia mai chiaramente.

Posso fare il colpo dell'esplosione del drago nero contro le bright sprite?

[fek]

Originariamente inviato da Ufo13

Ma che senso ha? Semplificherebbe un po' di test...

Non e` manco testabile poiche` il frame non cambia mai chiaramente.

Posso fare il colpo dell'esplosione del drago nero contro le bright sprite?

Se un'animazione con un solo frame nel gioco non e' mai usata, allora fai pure il colpo dell'esplosione del drago nero delle quattro vie di pechino anche su questo. E sui bright sprite.

[Ufo13]

Si` maestro. UATTAA

[71104]

Originariamente inviato da fek

Questo e' uno dei problemi della nostra batteria di test, problema che ho incontrato ieri: i test sono troppo pochi e a livello troppo alto. Facendo un piccolo cambiamento in BigGem mi sono ritrovato 10 test da 30 righe l'uno che fallivano. Ovviamente non avevo la piu' pallida idea del perche' fallissero, perche' erano a livello troppo alto.
Abbiamo bisogno di piu' test a livello piu' basso, che testano un solo piccolo comportamento in maniera chiara e inequivocabile di modo che un cambiamento nel codice che lo riguarda lo faccia fallire e il test indichi in maniera chiara il perche' del suo fallimento.

Al momento questo e' il nostro grosso limite che rende il lavoro di refactoring Diamonds poco piacevole, molto stressante e molto complesso.

post da incorniciare

[Jocchan]

Le bright gem salutiamole con la manina, ci hanno accompagnati a lungo ma è il momento di separarci per sempre da loro.
Idem le animazioni da un frame

[Ufo13]

Stasera hokutizzo le bright allora

[Jocchan]

Originariamente inviato da Ufo13

Stasera hokutizzo le bright allora

La stella della morte splende già su di loro

[fek]

Fede, per favore lavora anche su un REFACTOR THIS e indicalo nel commit description oppure fai il revert. La regola vale per tutti.

[Ufo13]

Fatto