Vai alla ricerca.
extremeprogramming-it · Discussion of Extreme Programming practices and principles (Italian)

Informazioni sul Gruppo

  • Iscritti: 688
  • Categoria: Programmazione
  • Data di creazione: Aug 10, 2000
  • Lingua: Italiano
? Già Iscritto? Entra su Yahoo!

Suggerimenti

Lo sapevi che...
Puoi cercare nel gruppo tutti i messaggi inviati.

Messaggi

  Messaggi Aiuto
Avanzata
Messaggi 2603 - 2632 di 11825   Più vecchio  |  < Meno recente  |  Più recente >  |  Più nuovo
Messaggi 2603 - 2632 di 11825   Più vecchio  |  < Meno recente  |  Più recente >  |  Più nuovo
Messaggi: Mostra riassunti messaggi Disponi per data ^  
#2603 Da: Enrico <emangano@...>
Data: Mer 3 Mag 2006 12:48 pm
Oggetto: ennesimo diario di bordo
emangano78
Invia email Invia email
 
Ciao a tutti,

con enorme umiltà volevo segnalarvi un piccolo diario di bordo
che traccia l'esperienza degli ultimi sette mesi circa sulla graduale
adozione di XP nel team di cui faccio parte.

I post sono raggiungibili sul mio blog (ebbene sì un altro blog!) sotto
la categoria Diario Di Bordo:

http://www.request.to.it/enri/index.php?d=27&m=04&y=06&category=4

Ovviamente critiche e/o commenti non sono graditi... di più! ;-)

--
Enrico Mangano
http://www.request.to.it/enri

#2604 Da: Giovanni Corriga <giovanni@...>
Data: Mer 3 Mag 2006 5:06 pm
Oggetto: Reminder: Smalltalk Party a Cagliari - 01/07/2006
giovanni@...
Invia email Invia email
 
Ciao a tutti,

Vi inoltro questo annuncio nel caso che qualcuno sia interessato alla
cosa.

Stiamo organizzando uno Smalltalk Party a Cagliari per il giorno sabato
1 luglio. Sarà una grande occasione per qualche chiacchierata
amichevole, per incontrare altri Smalltalker e per conoscere una
spendida parte d'Italia.

Il party si terrà nei locali dell'Università di Cagliari
( http://www.unica.it ) ed è sponsorizzato dall'Agile Group
( http://agile.diee.unica.it ).

Se siete interessati a venire al party, aggiungete il vostro nome allo
swiki
http://smalltalkit.seasidehosting.st/seaside/pier/SmalltalkParty20060701, oppure
mandate una email a giovanni@... .

Il wiki contiene anche delle informazioni turistiche che possono esservi
utili.

	 Giovanni

#2605 Da: "lucas shuun" <lucas.shuun@...>
Data: Mer 3 Mag 2006 5:36 pm
Oggetto: Re: [xp-it] ennesimo diario di bordo
lucas_rsi
Invia email Invia email
 
Ciao Enrico,
ti volevo ringraziare per il link al tuo diario di bordo, fino ad ora nei miei team non ne ho mai
fatto uso ma leggendo il tuo mi rendo conto che con l'andare del tempo diviene una fonte inestimabile di  informazioni/riflessioni/suggerimenti...

Ciao e grazie
Lucas

On 5/3/06, Enrico <emangano@...> wrote:
Ciao a tutti,

con enorme umiltà volevo segnalarvi un piccolo diario di bordo
che traccia l'esperienza degli ultimi sette mesi circa sulla graduale
adozione di XP nel team di cui faccio parte.

I post sono raggiungibili sul mio blog (ebbene sì un altro blog!) sotto
la categoria Diario Di Bordo:

http://www.request.to.it/enri/index.php?d=27&m=04&y=06&category=4

Ovviamente critiche e/o commenti non sono graditi... di più! ;-)

--
Enrico Mangano
http://www.request.to.it/enri


Collegamenti utili di Yahoo! Gruppi


#2606 Da: "C M" <artemixp@...>
Data: Gio 4 Mag 2006 1:20 pm
Oggetto: presentazione
yahrtemis
Invia email Invia email
 
Ciao a tutti,

Mi presento: lavoro come sviluppatrice essenzialmente Java (anche se
ultimamente col mio gruppo stiamo utilizzando Ruby per la parte di
Acceptance Testing) e per mia grande fortuna, ho iniziato quasi subito
a lavorare in contesti xp.

La mia esperienza lavorativa non è sicuramente decennale ;), ma la
reputo di qualita' e con risvolti estremamente formativi e di crescita
proprio in virtu' del valore aggiunto che XP riesce a portare, con i
suoi principi e le sue pratiche, alla professionalita' di noi
sviluppatori.

Non aggiungo altro, ma solo buon lavoro a tutti e grazie per tutti gli
spunti di riflessione nati da questa mailing list!

Ciao,

Claudia

#2607 Da: "Piergiuliano Bossi" <pgbossi@...>
Data: Gio 4 Mag 2006 4:23 pm
Oggetto: Re: [xp-it] presentazione
pgbossi
Invia email Invia email
 
On 5/4/06, C M <artemixp@...> wrote:
Ciao a tutti,

Mi presento: lavoro come sviluppatrice essenzialmente Java (anche se
ultimamente col mio gruppo stiamo utilizzando Ruby per la parte di
Acceptance Testing) e per mia grande fortuna, ho iniziato quasi subito
a lavorare in contesti xp.

Watir a go-go? Se hai voglia di parlarcene un po' penso possa essere interessante.

Benvenuta.
Ciao
Giuliano


#2608 Da: Roberto Gianassi <robertogianassi@...>
Data: Sab 6 Mag 2006 12:54 pm
Oggetto: Mi presento anch'io
robertogianassi
Invia email Invia email
 

Ciao a tutti,

innanzitutto complimenti per la mailing list! ;-)

Mi chiamo Roberto e lavoro nel settore della programmazione da 9 anni. Ho lavorato in vari ambiti (web, enterprise, scientifico e adesso quasi-automazione) , con vari linguaggi (C++ poi ASP, Java e adesso VB6) e con vari strumenti (da Visual Studio e precedenti a JBuilder e Eclipse).

Le metodologie agili di sviluppo software (tra cui XP) mi hanno sempre interessato molto anche se purtroppo non ho mai avuto la fortuna di lavorare in team XP.

Dato che sto valutando la possibilita' di cambiare aria lavorativa vi vorrei chiedere se siete a conoscenza di aziende "agili" nella zona tra Firenze, Prato e Pistoia.

Non so che contributo potro' dare a XP (a parte "spiare" questa ML).

Per ora buon lavoro e ciao alla prossima,

Roberto

No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.392 / Virus Database: 268.5.5/333 - Release Date: 05/05/2006

#2609 Da: Francesco Cirillo <francesco.cirillo@...>
Data: Sab 6 Mag 2006 5:55 pm
Oggetto: Re: [xp-it] Mi presento anch'io
francesco_xp...
Invia email Invia email
 
In bocca al lupo Roberto e benvenuto.

Francesco

Scrive Roberto Gianassi <robertogianassi@...>:

>
> Ciao a tutti,
>
> innanzitutto complimenti per la mailing list! ;-)
>
> Mi chiamo Roberto e lavoro nel settore della programmazione da 9 anni.
> Ho lavorato in vari ambiti (web, enterprise, scientifico e adesso
> quasi-automazione) , con vari linguaggi (C++ poi ASP, Java e adesso VB6)
> e con vari strumenti (da Visual Studio e precedenti a JBuilder e Eclipse).
>
> Le metodologie agili di sviluppo software (tra cui XP) mi hanno sempre
> interessato molto anche se purtroppo non ho mai avuto la fortuna di
> lavorare in team XP.
>
> Dato che sto valutando la possibilita' di cambiare aria lavorativa vi
> vorrei chiedere se siete a conoscenza di aziende "agili" nella zona tra
> Firenze, Prato e Pistoia.
>
> Non so che contributo potro' dare a XP (a parte "spiare" questa ML).
>
> Per ora buon lavoro e ciao alla prossima,
>
> Roberto
>
>


...........................
   Dott. Francesco Cirillo
   CEO, XPLabs SRL
   Coach, Bees Team
   Tel +39 06 452.14.734
   Tel +39 02 303.56.742
   Mob +39 338 76.35.115
   Fax +39 06 233.236.936
   Via dei Castagni, 22
   01015 Sutri (VT)
   http://www.xplabs.it
...........................

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

#2610 Da: brusso <barbara.russo@...>
Data: Lun 8 Mag 2006 9:48 am
Oggetto: Faculty seminar series at the Free University of Bolzano/Bozen - Erich Gamma
russo682002
Invia email Invia email
 
We are pleased to announce the following seminar.

No registration is needed.

For further information on the seminar series and on how to reach the
Faculty, please visit the web page

http://www.unibz.it/inf/csseminars/seminars2006/index.html?LanguageID=EN

09.05.06 - 09.05.06, 14:30-15:30 - Faculty of Computer Science, Free
University of Bolzano-Bozen, P.za Sernesi, 1, room D101

*The Eclipse Way*
/Erich Gamma/

	
</printerversions/newsfull.html?LanguageID=EN&contentid=3817&pageid=15&PV=TRUE&S\
HOW_CMD=FALSE>





   	 Abstract. Eclipse received awards for Best Value, Best Open Source
Tool and Most Improved Tool.

CV. Erich Gamma currently is an IBM Distinguished Engineer at IBM's
Object Technology International (OTI) lab in Zurich, Switzerland. He
provides leadership in the Eclipse community, and is responsible for the
Java development effort for the Eclipse platform. Erich Gamma lept onto
the software world stage in 1995 as co-author of the best-selling book
Design Patterns: Elements of Reusable Object-Oriented Software
(Addison-Wesley, 1995). This landmark work, often referred to as the
Gang of Four (GoF) book, cataloged 23 specific solutions to common
design problems. In 1998, he teamed up with Kent Beck to produce JUnit,
the de facto unit testing tool in the Java community.

Reference person: Barbara Russo <mailto: Barbara.Russo@...>

#2611 Da: "realknip" <nicola.canalini@...>
Data: Ven 12 Mag 2006 7:56 am
Oggetto: Agility e mia nonna
realknip
Invia email Invia email
 
Ho una lista infinita di "massime" che mia nonna mi ripete fin da
quando sono bambino, alcun di queste non le ho ancora capite (es. il
brodo fa venire le gambe grosse) altre le riconosco nella vita di
tutti i giorni. Una delle cose che mia nonna mi dice da sempre e':
"Fai una cosa alla volta".
Nel mio team siamo, by design, sottoposti a veloci context switch
perche' il numero dei progetti su cui lavoriamo (per lo piu'
manutenzione evolutiva) e' molto piu' alto del numero di sviluppatori,
ogni progetto ha poi piu' di un cliente con esigenze particolari.
Sulla carta il problema non esiste, cambi progetto ma cmq quando cambi
"dimentichi" il precedente e per quell'iterazione lavori ad una sola
cosa, nella pratica invece ...

Siccome un'altra massima di mia nonna e' che "vale piu' un'ora di
pratica che un mese di grammatica" vorrei avere il vostro feedback
sulla cosa. Anche a voi sperimentate difficolta' a "fare una cosa alla
volta" ? Vi pesa ?

Ciao
Nicola

#2612 Da: "Paolo \"Nusco\" Perrotta" <ml@...>
Data: Ven 12 Mag 2006 12:07 pm
Oggetto: Re: [xp-it] Agility e mia nonna
paoloperrotta
Invia email Invia email
 
realknip wrote:
> Siccome un'altra massima di mia nonna e' che "vale piu' un'ora di
> pratica che un mese di grammatica" vorrei avere il vostro feedback
> sulla cosa. Anche a voi sperimentate difficolta' a "fare una cosa alla
> volta" ? Vi pesa ?
>
Sì e sì. La cosa non è lineare. Se cambio contesto più volte a
settimana, allora due progetti insieme vanno ancora bene. Arrivato a
tre, si sentono sinistri scricchiolii. Più di quello, ho difficoltà a
fare progressi su ogni singolo progetto.

Le cose migliorano molto quando riesco a mettere insieme
un'infrastruttura per ridurre l'overhead del cambio di contesto. Se devo
andare a rileggere della documentazione o del codice lasciato a metà,
sono guai. Se tutto quello che devo fare per cambiare task è leggere una
lista di modifiche su un Wiki, fare un checkout e far girare i test,
allora riesco a parallelizzare meglio.

Quando il codice è tutto mio, o quando lavoro su un progetto dove non si
integra spesso, una tecnica che per me funziona benissimo è "leave the
last test broken". E' incredibile quanto faccia questo piccolo trucco
per riportarmi immediatamente con la testa nel punto dove avevo
interrotto il lavoro. Ancora non sono del tutto a mio agio con l'idea di
andare a dormire con una barra rossa, ma dopo un po' ci si abitua.

So che ci sono persone che non riescono a seguire più di un progetto
alla volta, e altre che sono perfettamente a proprio agio con tre o
quattro. E' in parte un fatto di abitudine, ma è anche una questione di
carattere, e in questo caso le forzature fanno male. "Chi nasce tondo
non muore quadro", dice mia nonna.

#2613 Da: "Carlo Bottiglieri" <carlo.bottiglieri@...>
Data: Ven 12 Mag 2006 1:38 pm
Oggetto: Re: [xp-it] Agility e mia nonna
inverno_3
Invia email Invia email
 

On 5/12/06, Paolo Nusco Perrotta <ml@...> wrote:
realknip wrote:

Quando il codice è tutto mio, o quando lavoro su un progetto dove non si
integra spesso, una tecnica che per me funziona benissimo è "leave the
last test broken". E' incredibile quanto faccia questo piccolo trucco
per riportarmi immediatamente con la testa nel punto dove avevo
interrotto il lavoro. Ancora non sono del tutto a mio agio con l'idea di
andare a dormire con una barra rossa, ma dopo un po' ci si abitua.

E' esattamente quello che faccio io per i progetti in solitaria! Che bello sapere che non sono l'unico eretico. Dopo averlo fatto le prime volte mi sentivo anch'io nervoso, però poi mi sono reso conto che per assicurarmi di avere una barra rossa alla fine quello che facevo non era lasciare del codice che non passa i tests, quanto piuttosto aggiungere un test che si aspetta dal codice qualcosa che ancora non fa. Non lasci qualcosa a metà, ti prepari il lavoro per la volta dopo.


#2614 Da: "Paolo \"Nusco\" Perrotta" <ml@...>
Data: Ven 12 Mag 2006 2:08 pm
Oggetto: Re: [xp-it] Agility e mia nonna
paoloperrotta
Invia email Invia email
 
Carlo Bottiglieri wrote:
> On 5/12/06, *Paolo Nusco Perrotta* <ml@...
> <mailto:ml@...>> wrote:
>
>
>     Quando il codice è tutto mio, o quando lavoro su un progetto dove
>     non si
>     integra spesso, una tecnica che per me funziona benissimo è "leave
>     the
>     last test broken".
>
>
> E' esattamente quello che faccio io per i progetti in solitaria! Che
> bello sapere che non sono l'unico eretico.


In realtà siamo anche troppo ortodossi... Ho preso la tecnica pari pari
dal libro Test-Driven Development di Kent Beck
(http://www.klaustrofobik.org/blog/archives/000208.html).

#2615 Da: "Carlo Bottiglieri" <carlo.bottiglieri@...>
Data: Ven 12 Mag 2006 2:18 pm
Oggetto: Re: [xp-it] Agility e mia nonna
inverno_3
Invia email Invia email
 

> E' esattamente quello che faccio io per i progetti in solitaria! Che
> bello sapere che non sono l'unico eretico.


In realtà siamo anche troppo ortodossi... Ho preso la tecnica pari pari
dal libro Test-Driven Development di Kent Beck
(http://www.klaustrofobik.org/blog/archives/000208.html).


Ah, allora Kent sarà contento di sapere che ha la mia approvazione ;)

Quel libro decisamente mi manca, devo provvedere.



#2616 Da: AinTz <aintz@...>
Data: Ven 12 Mag 2006 2:49 pm
Oggetto: Re: [xp-it] Agility e mia nonna
aintz
Invia email Invia email
 

Quel libro decisamente mi manca, devo provvedere.
Sicuro?
Lerning by doing...
...e infatti c'eri già...
 
= )
 
(...cmq bellissimi i vekki proverbi ke nn muoiono mai... -riferito a fai una cosa alla volta-)

Chiacchiera con i tuoi amici in tempo reale!
http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com


#2617 Da: "Alejandro Barrionuevo" <ale.barrionuevo@...>
Data: Mar 16 Mag 2006 1:06 pm
Oggetto: Re: [xp-it] whole team e leadership
barrionu
Invia email Invia email
 

Ci sono alcuni esempi molto interessanti in letteratura, come il concetto di sociocracy ( http://www.ternarysoftware.com/ pages/downloads/BrianRobertsonInterview2006-02-08.pdf ): personalmente non sono mai arrivato a tanto, ma è una lettura notevole e stimolante.



Ciao Piergiuliano,
Grazie per questo link. Mi è piaciuto tantissimo!
Mi chiedevo però se qualcuno sa dell'esistenza di una realtà di questo tipo in Italia.
Sono sempre alla ricerca e sarei contento di conoscere di più su questo argomento, anche con l'idea d'iniziare a tentare di portarla avanti anche in proprio...

Di nuovo grazie,

Alejandro


#2618 Da: "Paolo Bizzarri" <pibizza@...>
Data: Mer 17 Mag 2006 9:07 am
Oggetto: Strutturare il codice per migliorare la testabilità
pibizza
Invia email Invia email
 
Salve a tutti,

in ditta stiamo ragionando, in modo abbastanza intenso, su come strutturare il codice per migliorare la testabilità.

Ho mandato una domanda sulla mailing list di TDD, ma vorrei sottoporre la stessa domanda anche alle persone qui su xp-it.

Diciamo di avere una classe Core, e di voler testare un metodo chiamato doSomethingOnFolder.

def doSomethingOnFolder(self, folder_id):
    folder = self.getFolderFinder().findById(folder_id)
    if (folder.isAccessible()):
       document = self.getDocumentFinder().findByFolderId(folder_id)
       document.performSomething(folder.getTitle())

(La semantica esatta non è importante)

Quello che vorremmo testare, in questo caso, è come il flusso del metodo stesso: i.e., quali messaggi manda a quali oggetti.

Per farlo, siamo costretti ad utilizzare molti mock "profondi", nel senso che sono mock che ritornano altri mock che ritornano altri mock...

Per provare a migliorare le cose, abbiamo provato a incapsulare le interazioni con oggetti esterni in metodi privati, e a utilizzare il pattern Composite Method.

def doSomethingOnFolder(self, folder_id):
    folder = self._retrieveFolder(folder_id)
    if (self._isAccessible(folder)):
       document = self._retrieveDocument(folder_id)
       self._performSomething(folder)


Ora, i metodi tipo _retrieveFolder possono essere testati autonomamente, e anche in modo piuttosto semplice. Il problema è che il metodo doSomethingOnFolder deve ancora essere testato con una caterva di Mock intorno.

Tuttavia, il codice sembra (e sottolineo sembra) suggerire che potremmo separare i metodi helper dal flusso principale, e creare un oggetto separato:

Class Core:

def __init__(self, helper)
    self.helper = helper

def doSomethingOnFolder(self):
    folder = helper._retrieveFolder(folder_id)
    if (helper._isAccessible(folder)):
       document = helper._retrieveDocument(folder_id)
       helper._performSomething(folder)

class Helper:

  def _retrieveFolder(folder_id):
     return "something"

ecc...

In questa maniera, possiamo creare in fase di testing un MockHelper, che implementa la stessa interfaccia, ma ci rende le cose decisamente più semplici.

Idee e suggerimenti ?

Ciao

Paolo


#2619 Da: "Matteo Vaccari" <vaccari@...>
Data: Mer 17 Mag 2006 9:18 am
Oggetto: Re: [xp-it] Strutturare il codice per migliorare la testabilità
matteo_vaccari
Invia email Invia email
 
Non sono sicuro di avere capito bene; ma questa frase

>  Quello che vorremmo testare, in questo caso, è come il flusso del metodo
> stesso: i.e., quali messaggi manda a quali oggetti.

mi fa sospettare che in qualche modo dai per scontato e fissato il
design esistente.  Sarà che io tendo a ragionare più in termini di
stato che di interazioni, ma puoi spiegarci meglio perché è importante
testare la sequenza di chiamate?

Voglio dire, questi oggetti con cui devi parlare sono oggetti esterni
alla tua applicazione, e quindi il tuo requisito è che venga fatta
un'interazione con l'esterno con certe chiamate in un certo ordine,
oppure questi oggetti sono interni alla tua applicazione, e allora
potresti concentrarti di più sullo stato in cui vuoi farli arrivare?

Matteo

On 5/17/06, Paolo Bizzarri <pibizza@...> wrote:
>
>  Salve a tutti,
>
>  in ditta stiamo ragionando, in modo abbastanza intenso, su come strutturare
> il codice per migliorare la testabilità.
>
>
> Ho mandato una domanda sulla mailing list di TDD, ma vorrei sottoporre la
> stessa domanda anche alle persone qui su xp-it.
>
>  Diciamo di avere una classe Core, e di voler testare un metodo chiamato
> doSomethingOnFolder.
>
>  def doSomethingOnFolder(self, folder_id):
>      folder = self.getFolderFinder().findById(folder_id)
>      if (folder.isAccessible()):
>         document = self.getDocumentFinder().findByFolderId(folder_id)
>         document.performSomething(folder.getTitle())
>
> (La semantica esatta non è importante)
>
>  Quello che vorremmo testare, in questo caso, è come il flusso del metodo
> stesso: i.e., quali messaggi manda a quali oggetti.
>
>  Per farlo, siamo costretti ad utilizzare molti mock "profondi", nel senso
> che sono mock che ritornano altri mock che ritornano altri mock...
>
>  Per provare a migliorare le cose, abbiamo provato a incapsulare le
> interazioni con oggetti esterni in metodi privati, e a utilizzare il pattern
> Composite Method.
>
>  def doSomethingOnFolder(self, folder_id):
>      folder = self._retrieveFolder(folder_id)
>      if (self._isAccessible(folder)):
>         document = self._retrieveDocument(folder_id)
>         self._performSomething(folder)
>
>
>  Ora, i metodi tipo _retrieveFolder possono essere testati autonomamente, e
> anche in modo piuttosto semplice. Il problema è che il metodo
> doSomethingOnFolder deve ancora essere testato con una caterva di Mock
> intorno.
>
>  Tuttavia, il codice sembra (e sottolineo sembra) suggerire che potremmo
> separare i metodi helper dal flusso principale, e creare un oggetto
> separato:
>
>  Class Core:
>
>  def __init__(self, helper)
>      self.helper = helper
>
>  def doSomethingOnFolder(self):
>      folder = helper._retrieveFolder(folder_id)
>      if (helper._isAccessible(folder)):
>         document = helper._retrieveDocument(folder_id)
>         helper._performSomething(folder)
>
>  class Helper:
>
>    def _retrieveFolder(folder_id):
>       return "something"
>
>  ecc...
>
>  In questa maniera, possiamo creare in fase di testing un MockHelper, che
> implementa la stessa interfaccia, ma ci rende le cose decisamente più
> semplici.
>
>  Idee e suggerimenti ?
>
>  Ciao
>
>  Paolo
>
>  ________________________________
>  Collegamenti utili di Yahoo! Gruppi
>
>
> Per andare all'homepage del gruppo:
> http://it.groups.yahoo.com/group/extremeprogramming-it/
>
> Per annullare l'iscrizione al gruppo, scrivi a:
> extremeprogramming-it-unsubscribe@yahoogroups.com
>
> L'utilizzo da parte tua di Yahoo! Gruppi è soggetto alle Condizioni Generali
> di Utilizzo del Servizio.


--
http://matteo.vaccari.name

#2620 Da: Giovanni Corriga <giovanni@...>
Data: Mer 17 Mag 2006 9:43 am
Oggetto: Re: [xp-it] Strutturare il codice per migliorare la testabilità
giovanni@...
Invia email Invia email
 
Il giorno mer, 17/05/2006 alle 11.07 +0200, Paolo Bizzarri ha scritto:
>
> In questa maniera, possiamo creare in fase di testing un MockHelper,
> che implementa la stessa interfaccia, ma ci rende le cose decisamente
> più semplici.
>
> Idee e suggerimenti ?
>
Così d'istinto mi viene da pensare che la tua classe Core abbia troppe
responsabilità. Non puoi spostare la logica nella classe Folder?

	 Giovanni

>

#2621 Da: "Paolo Bizzarri" <pibizza@...>
Data: Mer 17 Mag 2006 9:48 am
Oggetto: Re: [xp-it] Strutturare il codice per migliorare la testabilità
pibizza
Invia email Invia email
 


On 5/17/06, Matteo Vaccari <vaccari@...> wrote:
Non sono sicuro di avere capito bene; ma questa frase

>  Quello che vorremmo testare, in questo caso, è come il flusso del metodo
> stesso: i.e., quali messaggi manda a quali oggetti.

mi fa sospettare che in qualche modo dai per scontato e fissato il
design esistente.  Sarà che io tendo a ragionare più in termini di
stato che di interazioni, ma puoi spiegarci meglio perché è importante
testare la sequenza di chiamate?

Voglio dire, questi oggetti con cui devi parlare sono oggetti esterni
alla tua applicazione, e quindi il tuo requisito è che venga fatta
un'interazione con l'esterno con certe chiamate in un certo ordine,
oppure questi oggetti sono interni alla tua applicazione, e allora
potresti concentrarti di più sullo stato in cui vuoi farli arrivare?


In realtà, il nostro obiettivo è esattamente quello di modificare il design esistente, ma (purtroppo...) molte parti del nostro codice non sono in questo momento adeguamente sottoposte a test.
 
Inoltre le parti del codice su cui ragiono spesso non hanno uno stato interno su cui ragionare, ma sono piuttosto oggetti che lavorano smistando informazioni da e verso altri oggetti.

Per questo abbiamo l'idea che il comportamento esterno osservabile sia rappresentato dai messaggi che gli oggetti trasmettono agli altri oggetti: in questo caso, le invocazioni di metodi.

Quello che voglio dire è che non vorrei essere costretto a scrivere test che devono lavorare su uno "stato del sistema" molto grande.

Ti faccio un esempio pratico, per capire:

   def autoDoIncomingRegistration(self, instance_id, workitem_id, **args):
        instance = self.getInstance(instance_id)
        protocol_data = instance.getProtocolData()
        self.getLogger().putLogMessage("Inserimento Registrazione Ingresso n. %d, ambito: %s, AOO: %s"  % (protocol_data.number(), protocol_data.kind(), protocol_data.areaCode()))
        registration_id =  instance._newRegistration()
        parent_id = self.getRegistrations()._newRegisteringEvent(registration_id)
        instance.setEventId(parent_id)
        command = AssignmentEventTracing(instance, registration_id, parent_id)
        self.startAssignmentAndNotify(instance, command)
        if instance.getProperty('to_scan', 0):
            self.startScanProcess(registration_id)
        return registration_id

questo metodo è invocato, in modo automatico, quanto una nostra istanza del workflow raggiunge un certo punto. Al metodo sono passati l'instance_id e il workitem_id, che permettono di recuperare l'istanza del processo.

Di fatto un metodo del genere non lavora su dati propri, ma fa eseguire "cose" ad altri oggetti, prendendo e smistando informazioni. Stiamo cercando di capire come spostare il codice in modo da renderlo più testabile e comprensibile.

Ciao

Paolo

#2622 Da: "Tommaso Torti" <t.torti@...>
Data: Mer 17 Mag 2006 12:28 pm
Oggetto: RE: [xp-it] Strutturare il codice per migliorare la testabilità
poetacaotico
Invia email Invia email
 
Ciao Paolo,



Alcune osservazioni sparse:

* Noto che sono accoppiate le operazioni di creazione e recupero di
informazioni.
Parlo, ad esempio, del registration_id e del parent_id. Se si svincolassero le 2
operazioni sarebbe tutto più comodo.
La creazione potrebbe tornare oggetti, non id. Poi tali oggetti potrebbero
comunicare tra loro. Per rendere concreto il pensiero:

** durante la creazione di instance:
         instance = self.getInstance(instance_id)
    il quale, al suo interno:
	 instance._newRegistration(), il quale registra come field il registration_id

** nel metodo autoDoIncomingRegistration(self, instance,**args):

         self.getRegistrations().newRegisteringEventFor(instance) // il quale, al
suo interno, setta l'eventID.

	 command = AssignmentEventTracing(instance) // recupera i registration_id,
parent_id tramite getter di "instance"

         self.startAssignmentAndNotify(instance, command)

         if instance.getProperty('to_scan', 0): 
self.startScanProcess(instance.registration_id)
         return instance.registration_id

Un test potrebbe passare una istanza di "instance" creata ad hoc e verificare
che, al termine dell'invocazione del metodo, l'event Id è aggiornato.
Un altro test può verificare il funzionamento del metodo quando è settata la
property "to_scan" e così via..

* Il log può essere una operazione a parte. Quindi, prima di chiamare
autoDoIncomingRegistration (che nell'esempio ha un argomento non usato) si
potrebbe chiamare una procedura di log, da eseguire dopo la creazione di
"instance" o dopo l'esecuzione della procedura autoDoIncomingRegistration

instance = self.getInstance(instance_id)
LogInserimentoRegistrazioneIngresso(self, instance) : ...
autoDoIncomingRegistration(self, instance **args): ...


Spero di averti suggerito buone idee ;-)
Buon lavoro,

Tommaso Torti

#2623 Da: "Paolo Bizzarri" <pibizza@...>
Data: Mer 17 Mag 2006 3:21 pm
Oggetto: Re: [xp-it] Strutturare il codice per migliorare la testabilità
pibizza
Invia email Invia email
 


On 5/17/06, Giovanni Corriga <giovanni@...> wrote:
Il giorno mer, 17/05/2006 alle 11.07 +0200, Paolo Bizzarri ha scritto:
>
> In questa maniera, possiamo creare in fase di testing un MockHelper,
> che implementa la stessa interfaccia, ma ci rende le cose decisamente
> più semplici.
>
> Idee e suggerimenti ?
>
Così d'istinto mi viene da pensare che la tua classe Core abbia troppe
responsabilità. Non puoi spostare la logica nella classe Folder?

        Giovanni


Sicuramente devo spostare la logica. Il problema è che non ho molti test in questa parte del codice, e volevo capire come organizzare il test.

Da questo è nata la riflessione su quali pattern seguire per organizzare il codice, in modo da rendere più semplice la testabilità del codice stesso.

Ciao

Paolo


#2624 Da: "Paolo Bizzarri" <pibizza@...>
Data: Mer 17 Mag 2006 3:20 pm
Oggetto: Re: [xp-it] Strutturare il codice per migliorare la testabilità
pibizza
Invia email Invia email
 


On 5/17/06, Tommaso Torti <t.torti@...> wrote:
Ciao Paolo,


Ciao Tommaso, 

Alcune osservazioni sparse:

* Noto che sono accoppiate le operazioni di creazione e recupero di informazioni.
Parlo, ad esempio, del registration_id e del parent_id. Se si svincolassero le 2 operazioni sarebbe tutto più comodo.


concordo. Il problema è che è codice legacy (purtroppo nostra legacy....) e che capire da che parte iniziare a smontarlo non è facile. Poi, ovviamente, le parti messe peggio sono quelle con meno test (forse sono quelle messe peggio perchè hanno meno test ? Probabile).
 

La creazione potrebbe tornare oggetti, non id. Poi tali oggetti potrebbero comunicare tra loro. Per rendere concreto il pensiero:

** durante la creazione di instance:
        instance = self.getInstance(instance_id)
   il quale, al suo interno:
        instance._newRegistration(), il quale registra come field il registration_id

Ok. Concordo che è più pulito.
 

** nel metodo autoDoIncomingRegistration(self, instance,**args):

         self.getRegistrations().newRegisteringEventFor(instance) // il quale, al suo interno, setta l'eventID.

        command = AssignmentEventTracing(instance) // recupera i registration_id, parent_id tramite getter di "instance"

        self.startAssignmentAndNotify(instance, command)

        if instance.getProperty('to_scan', 0):  self.startScanProcess(instance.registration_id)
        return instance.registration_id

Concordo. Mi torna abbastanza.
 

Un test potrebbe passare una istanza di "instance" creata ad hoc e verificare che, al termine dell'invocazione del metodo, l'event Id è aggiornato.
Un altro test può verificare il funzionamento del metodo quando è settata la property "to_scan" e così via..


Qui vorrei capire. Il mio problema era un po' come riuscire a organizzare il codice in modo che fosse maggiormente testabile, e anche ad elaborare uno o piu' pattern che avessero valenza "generale".

Io non vorrei tanto verificare se un certo valore della istance è stato settato, quanto piuttosto andare a vedere se alla istance è arrivato un certo messaggio. Se lui poi ha effettuato il test lo dovrà dire il test della istance.
 

* Il log può essere una operazione a parte. Quindi, prima di chiamare autoDoIncomingRegistration (che nell'esempio ha un argomento non usato) si potrebbe chiamare una procedura di log, da eseguire dopo la creazione di "instance" o dopo l'esecuzione della procedura autoDoIncomingRegistration

instance = self.getInstance(instance_id)
LogInserimentoRegistrazioneIngresso(self, instance) : ...
autoDoIncomingRegistration(self, instance **args): ...

 

Spero di averti suggerito buone idee ;-)
Buon lavoro,

Tommaso Torti


Sì, certo. Io volevo però riflettere insieme a voi su come organizzare, in generale, la struttura dei test degli oggetti.

Che ne pensi di quello che ho proposto nel primo post ?

Ciao e grazie.

Paolo


#2625 Da: "Tommaso Torti" <t.torti@...>
Data: Mer 17 Mag 2006 3:51 pm
Oggetto: RE: [xp-it] Strutturare il codice per migliorare la testabilità
poetacaotico
Invia email Invia email
 
>Io non vorrei tanto verificare se un certo valore della istance è stato
>settato, quanto piuttosto andare a vedere se alla istance è arrivato un
>certo messaggio.

Una soluzione potrebbe essere:

Si potrebbe creare un nuovo oggetto che estende quello under test ed esegue
override di tutti i metodi che vuoi testare.
Quindi, se vuoi testare che venga chiamato il metodo registerEventID(...)
sull'oggetto di tipo A, crei un oggetto di tipo B che estende A, ridefinisce
registerEventID in questo modo:

registerEventID (parametri ...) :
  e'statochiamatoilmetodoregistereventid = true
  super(parametri ...)

Il test accedera' a quell'informazione permettendoti di asserire che <<alla
istance è arrivato un certo messaggio>>.

Hai gia' provato qualcosa del genere? Se si' , quali difficolta' hai incontrato?

Ciao !

Tommaso Torti

#2626 Da: "Paolo Bizzarri" <pibizza@...>
Data: Mer 17 Mag 2006 4:03 pm
Oggetto: Re: [xp-it] Strutturare il codice per migliorare la testabilità
pibizza
Invia email Invia email
 


On 5/17/06, Tommaso Torti <t.torti@...> wrote:

>Io non vorrei tanto verificare se un certo valore della istance è stato
>settato, quanto piuttosto andare a vedere se alla istance è arrivato un
>certo messaggio.

Una soluzione potrebbe essere:

Si potrebbe creare un nuovo oggetto che estende quello under test ed esegue override di tutti i metodi che vuoi testare.
Quindi, se vuoi testare che venga chiamato il metodo registerEventID(...) sull'oggetto di tipo A, crei un oggetto di tipo B che estende A, ridefinisce registerEventID in questo modo:

registerEventID (parametri ...) :
e'statochiamatoilmetodoregistereventid = true
super(parametri ...)

Il test accedera' a quell'informazione permettendoti di asserire che <<alla istance è arrivato un certo messaggio>>.

Hai gia' provato qualcosa del genere? Se si' , quali difficolta' hai incontrato?


Che mi suona un po' "brutto"...

In altre parole, ho l'impressione che il codice mi stia dicendo qualcosa, e che io stia alzando il volume dello stereo per non ascoltarlo.

Quello che mi sembra dire è: "non ti sembra strano che per testare la classe A, tu debba costruire la classe B, derivandola da A ?"

L'impressione è che ci sia un altro oggetto "sotto", che sta premendo per emergere, l'oggetto che fornisce i metodi helper.

Ciao

Paolo



#2627 Da: "Tommaso Torti" <t.torti@...>
Data: Mer 17 Mag 2006 4:42 pm
Oggetto: R: [xp-it] Strutturare il codice per migliorare la testabilità
poetacaotico
Invia email Invia email
 
<<L'impressione è che ci sia un altro oggetto "sotto", che sta premendo per
emergere>>

...che emergerà una volta che avrai i test che ti supportano in questa
operazione ;-)

Si può anche osare una reificazione senza test, purchè tu abbia confidenza!

Tommaso Torti

#2628 Da: "Paolo Bizzarri" <pibizza@...>
Data: Mer 17 Mag 2006 5:01 pm
Oggetto: Re: R: [xp-it] Strutturare il codice per migliorare la testabilità
pibizza
Invia email Invia email
 


On 5/17/06, Tommaso Torti <t.torti@...> wrote:


<<L'impressione è che ci sia un altro oggetto "sotto", che sta premendo per
emergere>>

...che emergerà una volta che avrai i test che ti supportano in questa operazione ;-)

Si può anche osare una reificazione senza test, purchè tu abbia confidenza!

Tommaso Torti

Esatto.

Io volevo capire se si trattava di un modo di procedere "generale", che potevamo utilizzare per la costruzione dei test.

Stiamo cercando di avere un metodo unifome per la stesura dei test, pe evitare di testare le cose in 27 modi diversi (Solution Sprawl)...

Paolo

 



#2629 Da: Marco Tizzoni <elibus1978@...>
Data: Mer 17 Mag 2006 5:19 pm
Oggetto: Mi presento...
elibus1978
Invia email Invia email
 
Ciao a tutti.

Come buona educazione mi presento.

Sono un giovane catanese che ha deciso di emergere, o se volete, emigrato per
lavoro. :)
Partecipo da un bel po' di anni alle attivita' del FreakNet MediaLab (per chi
non lo conoscesse www.freaknet.org) e un ambiente moooooolto creativo e
stimolante.
La mia formazione e' tutta su sistemi operativi e reti, ma programmo per
diletto e necessita' di sysadmin. Partito da Win sono stato folgorato sulla
via di Damasco ed ho iniziato a studiare ed appassionarmi ai sistemi unix
(tutti meno SCO! :) ) ed alle reti. Dopo una buona dose di cisco mi sono
ritrovato (e sto cercando ancora di capire come...) a fare configuration
management.
La vera storia e' che potrei fare di tutto in informatica, vista la passione,
purche' il "tutto" non sia scontato.
Di XP, conosco il nome, ho sentito qlcs e ho conosciuto il buon Francesco, che
ritrovo qui... anzi direi che e' lui che ritrova me qui ;). Francesco mi ha
fatto incuriosire per cui eccomi qua!

Staro' "tunato" per vedere che succede.

A presto,
Marco

#2630 Da: AinTz <aintz@...>
Data: Mer 17 Mag 2006 7:06 pm
Oggetto: Re: [xp-it] Mi presento...
aintz
Invia email Invia email
 
...benvenuto...
 
=)
 
Enzo
 
 
 


Marco Tizzoni <elibus1978@...> ha scritto:
Ciao a tutti.

Come buona educazione mi presento.

Sono un giovane catanese che ha deciso di emergere, o se volete, emigrato per
lavoro. :)
Partecipo da un bel po' di anni alle attivita' del FreakNet MediaLab (per chi
non lo conoscesse www.freaknet.org) e un ambiente moooooolto creativo e
stimolante.
La mia formazione e' tutta su sistemi operativi e reti, ma programmo per
diletto e necessita' di sysadmin. Partito da Win sono stato folgorato sulla
via di Damasco ed ho iniziato a studiare ed appassionarmi ai sistemi unix
(tutti meno SCO! :) ) ed alle reti. Dopo una buona dose di cisco mi sono
ritrovato (e sto cercando ancora di capire come...) a fare configuration
management.
La vera storia e' che potrei fare di tutto in informatica, vista la passione,
purche' il "tutto" non sia scontato.
Di XP, conosco il nome, ho sentito qlcs e ho conosciuto il buon Francesco, che
ritrovo qui... anzi direi che e' lui che ritrova me qui ;). Francesco mi ha
fatto incuriosire per cui eccomi qua!

Staro' "tunato" per vedere che succede.

A presto,
Marco


Yahoo! Mail: gratis 1GB per i messaggi, antispam, antivirus, POP3

#2631 Da: Gabriele Lana <gabriele.lana@...>
Data: Mer 17 Mag 2006 10:56 pm
Oggetto: Re: [xp-it] Strutturare il codice per migliorare la testabilita'
gabrielelana
Invia email Invia email
 
mercoledi 17 maggio 2006, alle 11:48, il navigatore Paolo Bizzarri scrisse:

Mi permetto anch'io qualche piccolo pensiero:

1:
> In realtà, il nostro obiettivo è esattamente quello di
> modificare il design esistente, ma (purtroppo...) molte parti del
> nostro codice non sono in questo momento adeguamente sottoposte a
> test.

2:
> Inoltre le parti del codice su cui ragiono spesso non hanno uno
> stato interno su cui ragionare, ma sono piuttosto oggetti che
> lavorano smistando informazioni da e verso altri oggetti.

3: Il codice che hai postato, tipo
def autoDoIncomingRegistration(self, instance_id, workitem_id, **args):
   instance = self.getInstance(instance_id)
   protocol_data = instance.getProtocolData()
   self.getLogger().putLogMessage(
  	 "Inserimento Registrazione Ingresso n. %d, ambito: %s, AOO: %s" % (
		 protocol_data.number(),
		 protocol_data.kind(),
		 protocol_data.areaCode()))
   registration_id =  instance._newRegistration()
   parent_id = self.getRegistrations()._newRegisteringEvent(registration_id)
   instance.setEventId(parent_id)
   command = AssignmentEventTracing(instance, registration_id, parent_id)
   self.startAssignmentAndNotify(instance, command)
   if instance.getProperty('to_scan', 0):
     self.startScanProcess(registration_id)
   return registration_id

4: L'utilita' dei mock all'interno dei test
5: L'idea di utilizzare degli Helper

Sono tutti indicatori sintomatici di codice procedurale, se mi
chiedessero di descrivere il codice di cui sopra, direi immediatamente
che si tratta di un "mediator", che di per se non avrebbe nulla di
sbagliato, ma quando iniziano ad essercene troppi di mediator...

Facciamo alcune considerazioni:
- a prima occhiata sembra un po' lungo
- interagisce con un po' troppi oggetti (come hai fatto notare)
- "invidia" un po' troppo i dati degli oggetti con cui interagisce
   (bad smell: features envy)
- "conosce" un po' troppo il funzionamento degli oggetti con cui
   interagisce => questo bad smell e' facilmente riconoscibili quando
   trovi degli accoppiamenti temporali fra le chiamate di metodi,
   ovvero si vengono a creare spontaneamente dei "pattern" di codice
   che si ripetono un po' ovunque

Come procederei io? Nella maniera piu' pragmatica possibile inizierei
a costruire degli "smoke test", ovvero dei test funzionali (non
unitari) che ti possono dare una ragionevole rete di sicurezza.
Prenderei i metodi di cui sopra e inizierei a fare piccoli passi di
refactoring del tipo:
- descrivi in speudo codice ad altissimo livello il metodo da
   rifattorizzare
- per ogni passo di pseudo codice identifica il blocco di codice
   relativo o commentalo nel modo piu' breve e comunicativo possibile
- estrai ogni blocco in un metodo a parte il cui nome rievochera' il
   commento che avevi dato precedentemente al blocco
Ora, guardando questi nuovi metodi, molto probabilmente quei metodi
starebbero molto meglio se appartenessero ad altre classi (features
envy), spostando i metodi nelle relative classi di appartenenza si
avrebbero a questo punto dei metodi che agiscono direttamente con i
dati delle istanze di quella classe, metodi perfettamente testabili
senza l'ausilio di mock. Per farti un'idea piu' concreta potresti
leggerti un saggio dei PP: "Keep It DRY, Shy, and Tell the Other Guy"
http://www.pragmaticprogrammer.com/articles/may_04_oo1.pdf

Perche' i mock nel tuo caso non sarebbero una soluzione? Tu stesso hai
detto che il vostro obiettivo e' quello di cambiare il design attuale,
i mock non farebbero altro che peggiorare la situazione rendendo molto
piu' lento il cambiamento. Pensaci bene, imbrigliando la comunicazione
innescata dal metodo di cui sopra, come pensi di poterlo modificare
successivamente se non modificando anche il test?

Perche' gli helper non sarebbero una soluzione? Perche' con gli helper
stai cercando di catturare i "pattern" di cui parlavo prima, "pattern"
che sono strettamente legati al funzionamento interno di alcuni
oggetti del tuo sistema, isolare questi "pattern" all'interno di
anonime classi helper contribuirebbe a rendere ancora piu' procedurale
il codice esistente, senza renderlo piu' testabile (la modalita' di
test piu' appetibile sarebbe ancora quella di utilizzare i mock)

I mock sono molto utili quando l'interazione fra un oggetto (l'oggetto
da testare) e gli altri conoscenti e' direttamente dipendente dallo
stato in cui si trova l'oggetto stesso. Un caso tipico e' quello di un
parser sax: a fronte di una sequenza di eventi esterni (elementi di un
documento xml), il parser invoca su determinati oggetti determinati
metodi, i quali possono a loro volta modificare lo stato del parser.
In sostanza quindi una complessita' combinatoria di eventi e stati che
devono poter essere testati. Nel metodo di cui sopra, secondo il mio
parere, utilizzando dei mock testeresti solamente la capacita'
dell'interprete python di interpretare le invocazioni di metodi
elencate e niente altro

Scusate la lungaggine, e gli errori che ci saranno... vista l'ora

--
Gabriele Lana
contact me at gabriele dot lana at agilemovement dot it
http://www.agilemovement.it - Italian Agile Movement
http://www.xpug.it - italian eXtreme Programming User Groups

#2632 Da: "Giorgio Vespucci" <giorgio.vespucci@...>
Data: Ven 19 Mag 2006 12:18 pm
Oggetto: Come testare web-chiama-web?
freak7019
Invia email Invia email
 
Ciao a tutti :)
Ho un quesito per voi.
Abbiamo per le mani una specie di SSO, realizzata con due servlet
deployate su due web container diversi; nella fattispecie 2 Tomcat.
I/Le 2 servlet si scambiano comandi (action) del tipo
login/logout/cambiaPwd/pwdCambiata/cambiaRuolo/ruoloCambiato e dati di
sessione via Cookie e/o via JSESSIONID.
In questo momento il codice è 'legacy', nel senso che non siamo in
grado di testare in maniera automatica una determinata sequenza di
action e i loro risultati, perchè ci sono di mezzo svariati controlli
cookie/non cookie/url rewriting/url non rewriting che non ho le
conoscenze per poter 'mockare'... :(

La domanda da 100 milioni di pistole è: come si testa un truschino del genere?

Grazie
Ciao
--
Giorgio Vespucci
giorgio.vespucci@...

Messaggi 2603 - 2632 di 11825   Più vecchio  |  < Meno recente  |  Più recente >  |  Più nuovo
Messaggi 2603 - 2632 di 11825   Più vecchio  |  < Meno recente  |  Più recente >  |  Più nuovo
Avanzata

Copyright ? 2010 Yahoo! Tutti i diritti riservati.
La Tua Privacy - Testo aggiornato - Condizioni generali di utilizzo del servizio - Linee guida - Aiuto

?