Newsgroup: it.comp.os.linux.development
Titolo: Tool per automatizzare i test sui programmi.

Ciao a tutti,
qualcuno sa se esistono tool per linux che permettano di effettuare
automaticamente una serie di test su un programma (magari anche registrando
gli spostamenti del mouse)?
GRAZIE
Daniele.

 gli spostamenti del mouse)?
E' un programma che stai sviluppando tu?  Lo unit testing in genere si
fa a livello di classi.  Il testing delle GUI e` considerato
all'unanimita` una gran gatta da pelare, percio` e` meglio separare
quanto piu` possibile l'interfaccia dalla logica di controllo e creare
test automatici solo per quest'ultima.
Massimiliano

 test automatici solo per quest'ultima.
No, in realtà era una domanda generale.
Ho sentito parlare di test regressivi
http://www.eptacom.net/pubblicazioni/pub_it/debug.html
 e volevo sapere se
esistevano tool per linux.
GRAZIE
Daniele.

"Massimiliano Mirra" <ba...@prism.localnet> ha scritto nel messaggio
news:slrna02g7...@prism.localnet...

Scusami, mi hai risposto per e-mail, mettendo un indirizzo nospam e non
specificando qual'è il tuo indirizzo vero! Così non posso ovviamente
risponderti!

 risponderti!
Ooops!  E' stata una svista quella di risponderti via email, non di
mettere l'indirizzo nospam.  Ho il dito veloce sulla `r' grazie a
mutt, e qualche volta mi dimentico che sto usando slrn (`f' per
followup, `r' per risposta privata).  Rispondimi pure qua.
Massimiliano

 Massimiliano
Ho assistito ad una conferenza su XP giusto una settimana fa, ma non
ritengo sia molto efficace al di fuori di determinati campi di sviluppo.
Infine, il mettere le asserzioni nel sorgente della classe stessa è alla
base del
Design by Contract di Meyer, e non è nulla di antiquato.

 ritengo sia molto efficace al di fuori di determinati campi di sviluppo.
``Ho visto la copertina di un libro giusto una settimana fa, ma non
ritengo che ci sia qualcosa di utile per me al suo interno.''
Puo` essere un'ipotesi corretta, puo` essere un'ipotesi sbagliata, ma
finche' non leggo il libro rimane un'ipotesi.  E' la solita dissonanza
tra conoscenza ed esperienza, e perdonami la filosofia spicciola.
(Non fraintendermi: e` una dissonanza sacrosanta e necessaria, non
abbiamo giornate da settantadue ore, ma in certi casi, come credo in
questo, svia.)
Non so quali delle tante pratiche raccolte sotto l'ombrello della XP
tu abbia in mente.  Io ho parlato esplicitamente dello unit testing.
Da quando l'ho adottato, sia la mia produttivita` sia l'affidabilita`
del mio codice sono schizzati alle stelle.  Campo di sviluppo: ovunque
ci sia da scrivere una classe.  Non esattamente una nicchia...).  Non
tornerei indietro per nulla al mondo.
Ammetto, comunque, che la mia posizione puo` essere dovuta all'ottimo
testing framework del linguaggio che sto usando (Ruby), e forse non
sono al corrente di difficolta` in ambiente C++ et similia.
Massimiliano 

 tu abbia in mente.  Io ho parlato esplicitamente dello unit testing.
Scusa, effettivamente io avevo in mente il continuo refactoring e il "non
partire da un design iniziale", che mi
hanno portato a pensare che tale processo di sviluppo si adatti meglio al
campo finanziario.
Però mi hai incuriosito riguardo il testing: hai un buon link su questa
parte dello sviluppo in XP?
GRAZIE
Daniele.

 parte dello sviluppo in XP?
Ecco, dopo che mi hai detto dell'effetto che ha avuto su di te la
conferenza, sono un po' restio a segnalarti parole parole parole. ;-)
L'ideale sarebbe che mi dicessi che linguaggio di programmazione usi,
e se posso ti segnalo qualcosa di pratico, che ti permetta di provarlo
``live'' senza rimpinzarti di concetti e teorie inutili.
Intanto ti posto un esempio da un mio progetto in corso, una struttura
di oggetti distribuiti client/server.  Anche non conoscendo il Ruby
dovrebbe risultare abbastanza leggibile.
Ho eliminato le parti ``di servizio'', che non hanno a che fare con il
test.  In genere i test per una classe XYZ sono incapsulati in una
classe TestXYZ (io ho barato, ho creato piu` classi con nomi diversi a
seconda dell'aspetto che testano). ``initialize'' naturalmente viene
eseguito una volta sola all'istanziazione della classe di test;
``setup'' viene eseguito prima di ogni test; ``assert_equal'' e` uno
dei tipi di asserzioni disponibili.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
class TestConnections 
  def initialize
    @server = Server.new
    DRb.start_service(nil, @server)
    @server_uri = DRb.uri
  end
  def setup
    names = ["jack", "sam", "tom"]
    @clients = Hash.new
    names.each do |name|
      @clients[name] = Client.new(name, @server_uri)
    end
  end
  def testOnline
    assert_equal(false, @clients["jack"].online?)
    @clients["jack"].login
    assert_equal(true, @clients["jack"].online?)
    @clients["jack"].logout
    assert_equal(false, @clients["jack"].online?)
  end
  def testLoginLogout
    assert_equal(true, @clients["jack"].login)
    assert_equal(false, @clients["jack"].login)
    assert_equal(true, @clients["jack"].logout)
    assert_equal(false, @clients["jack"].logout)
  end
  def testNoDuplicateNames
    first = Client.new("andy", @server_uri)
    second = Client.new("andy", @server_uri)
    assert_equal(true, first.login)
    assert_equal(false, second.login)
    assert_equal(true, first.online?)
    assert_equal(false, second.online?)
    first.logout
  end
end  
TestRunner.run(TestConnections)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Questo e` l'output:
Loaded suite TestConnections
Started...
..............
Finished in 1.839029 seconds.
3 runs, 11 assertions, 0 failures, 0 errors
Massimiliano

 ``live'' senza rimpinzarti di concetti e teorie inutili.
v. sopra: a me interessa la teoria, cmq io uso C++, java e Eiffel.
Comunque sto per comprare il libro di Kent Beck, che ne dici, ne vale la
pena?
GRAZIE
Daniele.

 pena?
Non lo conosco, ma a naso, direi di no.  Sara` un po' come leggere un
corso di scacchi senza giocare...  noioso e inconcludente.  Comunque,
se vuoi assaggiare qualcosa, potresti provare il libro in .pdf su
xprogramming.com
, l'ho appena scoperto e credo mi assocero` nella
lettura. :-)
Massimiliano

 lettura. :-)
quello che ti dico dovrebbe essere il libro di uno di quelli che "ha
inventato"
XP! Sono d'accordo che è necessario provare, ma come faccio a provare
senza avere un libro che mi indichi COSA provare?!   ;-)
P.S. visto che tu mi stai aiutando a conoscere una pratica che può essermi
importante
per scrivere codice "good, cheap and fast", io vorrei permettermi di
consigliarti di
leggere (se non lo hai già fatto) qualcosa che è stato molto importante per
la mia
crescita come programmatore: dai un'occhiata a qualche articolo di C. Pescio
che trovi su 
www.eptacom.net
 .
GRAZIE
--
Daniele Pallastrelli
pallas...@ieee.org
----------------------------------------------------------------------------
-------
In theory, there's no difference between theory and practice, but in
practice there is.

 che trovi su 
www.eptacom.net
 .
Vado.  Non l'ho fatto prima perche', come avrai notato da quest'area,
mi sono dedicato un po' di piu` a scriver codice. :-)
Massimiliano