Ripresa del progetto, primi passi

[^TiGeRShArK^]

Originariamente inviato da fek

Sistemato io.
Era impazzito svn che pretendeva di fare il merge di build.xml
Mi e' gia' successo.

..a me in locale va tutto..
...e infatti la build ora è VERDE
...ma è normale?
..o la build machine lo fa apposta solo per farmi sclerare?
EDIT: ah.. hai sistemato tutto il build... capito
..acnhe se mi sfugge come ha fatto a fare il merge dato che quello di solito lo fa in update e non in commit

[fek]

Per qualche motivo al momento dell'update della build machine ha deciso che doveva fare il merge :|
Ho cancellato build.xml, update, ed e' ripartito tutto.

[^TiGeRShArK^]

Originariamente inviato da fek

Per qualche motivo al momento dell'update della build machine ha deciso che doveva fare il merge :|
Ho cancellato build.xml, update, ed e' ripartito tutto.

ah..ecco..capito...
In effetti era il minimo dopo aver beccato il bug di svn, dopo non aver trovato come lockare il repository da subclipse e dopo che federico mi faceva un commit al minuto...

[VICIUS]

Ci sono molte classi che nel sorgente hanno delle createForTesting() e fanno riferimento a delle classi che ora sono in tests/src. Non sarebbe meglio spostare queste funzioni in altra sede? Come è ora è impossibile creare degli eseguibili con ant dist senza includere tutti i test e junit.

[fek]

Originariamente inviato da VICIUS

Ci sono molte classi che nel sorgente hanno delle createForTesting() e fanno riferimento a delle classi che ora sono in tests/src. Non sarebbe meglio spostare queste funzioni in altra sede? Come è ora è impossibile creare degli eseguibili con ant dist senza includere tutti i test e junit.

Preferirei tenere createFortTesting() dove sono ma cercare di scriverle senza riferimenti cio' che e' in tests/src. Pensi sia possibile?
Ma perche' non esiste la compilazione condizionale in java
(Perche' e' cosa buona e giusta)

[redcloud]

Originariamente inviato da redcloud

Altra domanda... perchè è stato scelto un numero pari di colonne?

Up

[thebol]

ci sono anche io.
In pausa pranzo mi scarico il repository, e poi incomincio a dare un occhiata in giro per il refactoring

[VICIUS]

Originariamente inviato da redcloud

Up

Dovevamo metterne uno dispari? Perché?

[VICIUS]

Originariamente inviato da fek

Preferirei tenere createFortTesting() dove sono ma cercare di scriverle senza riferimenti cio' che e' in tests/src. Pensi sia possibile?
Ma perche' non esiste la compilazione condizionale in java
(Perche' e' cosa buona e giusta)

Purtroppo sono usate praticamente solo per creare i mock e poi usarli nei posti giusti dei vari costruttori. Non mi piace molto come idea ma potremmo ricorrere ad una factory in tests/src che si preoccupi di fare solo queste cose.

[fek]

Originariamente inviato da VICIUS

Purtroppo sono usate praticamente solo per creare i mock e poi usarli nei posti giusti dei vari costruttori. Non mi piace molto come idea ma potremmo ricorrere ad una factory in tests/src che si preoccupi di fare solo queste cose.

Hmmm capisco. Valuta tu la cosa migliore. L'idea di avere questo coupling fra code base e test non mi piace.

[^TiGeRShArK^]

Originariamente inviato da VICIUS

Ci sono molte classi che nel sorgente hanno delle createForTesting() e fanno riferimento a delle classi che ora sono in tests/src. Non sarebbe meglio spostare queste funzioni in altra sede? Come è ora è impossibile creare degli eseguibili con ant dist senza includere tutti i test e junit.

...perchè?
non basta usare exclude name="**/test/**"? (o qualcosa del genere...) nel target jar (o dist.. o quello che è che non ho il codice sottomano ora)
EDIT.. ah capito forse...
ma perchè prima della mia modifica non avevamo lo stesso problema?

[VICIUS]

Originariamente inviato da ^TiGeRShArK^

...perchè?
non basta usare exclude name="**/test/**"? (o qualcosa del genere...) nel target jar (o dist.. o quello che è che non ho il codice sottomano ora)
EDIT.. ah capito forse...
ma perchè prima della mia modifica non avevamo lo stesso problema?

Ma se escludi la cartella dei test nel jar non finisco i class dei vari Mock e poi l'eseguibile non parte.

[fek]

Originariamente inviato da VICIUS

Ma se escludi la cartella dei test nel jar non finisco i class dei vari Mock e poi l'eseguibile non parte.

Si puo' scrivere qualcosa che carichi quei Mock solo quando vengono usati?

[cdimauro]

La soluzione potrebbe essere quella di ridurre i "componenti base" a interfacce, e di realizzarne poi due implementazioni diverse dove serve, una per il codice di produzione e una per il test.

Esempio: AudioInterface -> AudioEngine (produzione) + MockAudio (test).

In questo modo dovremmo separare del tutto il codice di test da quello di produzione.

[fek]

Originariamente inviato da cdimauro

La soluzione potrebbe essere quella di ridurre i "componenti base" a interfacce, e di realizzarne poi due implementazioni diverse dove serve, una per il codice di produzione e una per il test.

Esempio: AudioInterface -> AudioEngine (produzione) + MockAudio (test).

In questo modo dovremmo separare del tutto il codice di test da quello di produzione.

Buona soluzione anche questa.

[VICIUS]

Originariamente inviato da fek

Si puo' scrivere qualcosa che carichi quei Mock solo quando vengono usati?

Alla reflection non avevo pensato. Di sicuro ci sarà qualcosa di simile ad Assemble.Load di c# solo che ho il timore che venga fuori un mostro anche per una cosa così semplice. In ogni caso questa sera mi informo meglio e vedo che rimedio.

Originariamente inviato da cdimauro

La soluzione potrebbe essere quella di ridurre i "componenti base" a interfacce, e di realizzarne poi due implementazioni diverse dove serve, una per il codice di produzione e una per il test.

Esempio: AudioInterface -> AudioEngine (produzione) + MockAudio (test).

In questo modo dovremmo separare del tutto il codice di test da quello di produzione.

Anche usando interfacce se poi lasciamo la createForTesting() nell'oggetto di produzione il problema non si ripresenta come ora?

[cdimauro]

Ho sempre odiato i vari CreateForTesting...

Originariamente inviato da VICIUS

Anche usando interfacce se poi lasciamo la createForTesting() nell'oggetto di produzione il problema non si ripresenta come ora?

No, perché la mia idea è quella di eliminare proprio quei metodi.

In pratica nel codice dei test istanzio soltanto oggetti Mock*, mentre nel codice di produzione soltanto oggetti *Engine.

Non esiste nessuna CreateForTesting. Si usano i costruttori delle rispettive implementazioni quando e dove servono.

[Ufo13]

Hmmm non so voi ma a me avere 20000 interfacce non piace moltissimo e si finisce nell'antipattern del ravioli code. Quando si parla di classi Mock non abbiamo scelta ma per la creazione degli oggetti esistono soluzioni differenti.

Concordo con Cesare, i createForTesting non dovrebbero essere nelle classi di produzione. Non hanno assolutamente senso, spesso creano l'oggetto con parametri default, tanto vale avere le creazioni nelle varie classi test helper tipo EnvironmentTestCase etc...

[redcloud]

Originariamente inviato da VICIUS

Dovevamo metterne uno dispari? Perché?

Perchè vedere i pezzi che scendono dalla colonna in modo decentrato è uno strazio. Mi si disallinea il cervello

[cdimauro]

Originariamente inviato da Ufo13

Hmmm non so voi ma a me avere 20000 interfacce non piace moltissimo e si finisce nell'antipattern del ravioli code. Quando si parla di classi Mock non abbiamo scelta ma per la creazione degli oggetti esistono soluzioni differenti.

Concordo con Cesare, i createForTesting non dovrebbero essere nelle classi di produzione. Non hanno assolutamente senso, spesso creano l'oggetto con parametri default, tanto vale avere le creazioni nelle varie classi test helper tipo EnvironmentTestCase etc...

A me non piace avere mille interfacce. Anzi, generalmente non amo particolarmente il design-by-interface (mi piace usare le interfacce quando "sento" che mi servono veramente).

Sarebbe bello poter usare indifferentemente gli stessi oggetti sia in produzione che in fase di test, ma spesso non si può perché... in fase di test non posso creare un display, ad esempio.

E' chiaro, quindi, che le interfacce a cui mi riferiscono servono soltanto per definire il comportamento di oggetti che necessariamente debbono avere un comportamento diverso in fase di produzione e in fase di test. Da cui, quindi ricavare i vari *Engine e Mock*.

Per quanto mi riguarda, meno interfacce (e relativi Mock) usiamo, e meglio è.