Re: [Python] pytest e classi

[Manlio Perillo]

2015-10-28 10:56 GMT+01:00 enrico franchi :
> [...]
>> Tempo fa avevo sviluppato una libreria per l'unit testing in C (oddio,
>> quanto codice ho che non ho mai publicato...).
>> La libreria usa il protocollo TAP, eppure avevo deciso di interrompere
>> l'esecuzione della funzione di test
>> in caso di fallimento, anche se non necessario (usando longjmp),
>> perchè mi sembrava la scelta più ragionevole.
>
>
> Eh... come dicevo, fanno tutti cosi', e' sensato farlo anche solo per
> semplificare il ragionamento ai tuoi utenti.
> Sebbene, a mio avviso, ancora una volta Go rompe gli schemi per fare la cosa
> giusta.
>

Go può farlo perchè è safe rispetto a C.
In C se vuoi continuare dovresti gestire SIGSEV, cosa non banale e non
portabile.

>>
>>
>> Non so perchè ero convinto che il test fosse interrotto in caso di
>> fallimento, anche se la documentazione
>> è chiara.
>>
>
> Ci sono anche funzioni che ti danno questa semantica. Semplicemente scegli
> quello che ti serve.
> Magari eri abituato ad usare quelle e non ti eri guardato quelle altre.
>

No, uso le funzioni giuste.
Semplicemente essendo abituato a unittest di Python normali, il mio
cervello si aspetta una conferma su console (RUN/PASS) per ciascun
test nella *tabella*.
Ieri ho eseguito per la prima volta un test del genere su un progetto
Go, e quando ho letto il tuo commento mi ero fatto l'idea sbagliata.

Ciao  Manlio
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] pytest e classi

[Manlio Perillo]

2015-10-28 15:24 GMT+01:00 enrico franchi :
>
>
> 2015-10-28 11:38 GMT+00:00 Manlio Perillo :
>>
>>
>> > Eh... come dicevo, fanno tutti cosi', e' sensato farlo anche solo per
>> > semplificare il ragionamento ai tuoi utenti.
>> > Sebbene, a mio avviso, ancora una volta Go rompe gli schemi per fare la
>> > cosa
>> > giusta.
>> >
>>
>> Go può farlo perchè è safe rispetto a C.
>> In C se vuoi continuare dovresti gestire SIGSEV, cosa non banale e non
>> portabile.
>
>
> Si, ok, ci sono un po' di cose diverse, ma non direi che quello e' il
> problema.
>
> Spiego meglio: in C potresti fare una suite di test che invece che usare una
> qualche funzione "assertOk" che ti vola fuori dalla funzione chiamante in
> caso di problemi (ovviamente tutto bello integrato con la libreria di
> testing) utilizza una funzione "error" analoga alla funzione omonima di Go.
> [...]

> Detto questo, devi *comunque* gestire SIGSEV,

Si, alla fine credo sia la cosa migliore, eseguendo il codice in un
processo separato come suggerisci.
Magari se ho tempo lo implemento per la mia libreria, anche se
probabilmente non la userò molto.
Forse usando fork/vfork (e ignorando Windows) si riesce a fare anche
in modo abbastanza semplice,
anche perchè genero un file TAP su stdout, ma ci dovrei pensare meglio.


Ciao  Manlio
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] pytest e classi

[enrico franchi]

2015-10-28 11:38 GMT+00:00 Manlio Perillo :

>
> > Eh... come dicevo, fanno tutti cosi', e' sensato farlo anche solo per
> > semplificare il ragionamento ai tuoi utenti.
> > Sebbene, a mio avviso, ancora una volta Go rompe gli schemi per fare la
> cosa
> > giusta.
> >
>
> Go può farlo perchè è safe rispetto a C.
> In C se vuoi continuare dovresti gestire SIGSEV, cosa non banale e non
> portabile.
>

Si, ok, ci sono un po' di cose diverse, ma non direi che quello e' il
problema.

Spiego meglio: in C potresti fare una suite di test che invece che usare
una qualche funzione "assertOk" che ti vola fuori dalla funzione chiamante
in caso di problemi (ovviamente tutto bello integrato con la libreria di
testing) utilizza una funzione "error" analoga alla funzione omonima di Go.

Detto questo, devi *comunque* gestire SIGSEV, perche' al di la di tutto uno
puo' sempre avere un baco nel codice che scoppia con SIGSEV e quello che
vorresti e' che il processo che sta facendo girare i test non muoia
immediatamente ma esegua gli altri test. Il che e' chiaramente un problema
non da poco, visto che SUSv3 ti dice chiaro e tondo che i seguenti
comportamenti sono undefined behavior:
1. ritornare dal sig handler
2. bloccarlo
3. ignorarlo

Per cui di fatto l'unica cosa che potresti fare e' pulire quello che devi
pulire, eventualmente salvare un po' di stato da qualche parte (che so...
statistiche per il test runner o qualunque cosa) e poi comunque uscire.

Quindi credo di avere capito quello che intendevi... ma non credo sia un
problema. Nel senso che per come funziona C, di fatto, devi eseguire i vari
test in processi separati (perche' troppe cose possono mandare in undefined
behavior il tutto, quindi non puoi avere un singolo processo che esegue
tutti i test). Detto questo puoi offrire Error con la semantica di Go. Se
poi per qualunque motivo devi abortire (SIGSEV e' solo uno dei casi),
vorra' dire che il gestore di test scoprira' che quello specifico test e'
fallito [e potenzialmente avra' qualche informazione aggiuntiva]. Mi
verrebbe anche da dire che se vuoi usare  ptrace (e probabilmente lo vuoi
fare) ti da anche una struttura molto piu' logica.



-- 
.
..: -enrico-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] pytest e classi

[enrico franchi]

2015-10-27 19:29 GMT+00:00 Manlio Perillo :

> 2015-10-27 15:51 GMT+01:00 enrico franchi :
> > [...]
> >> La libreria standard di Go usa questo metodo, ed in effetti può essere
> >> visto come un problema.
> >
> >
> > In realta' non lo e'. Il punto e' che tutto questo discorso dei test e'
> nato
> > attorno ad una primitiva come assert che quando hai un problema
> > essenzialmente interrompe l'esecuzione li (tipicamente tirando
> un'eccezione)
> > e quindi le asserzioni successive non vengono eseguite.
> >
>
> Questo comportamento non è del tutto irragionevole.
>

No, non e' interamente irragionevole. Ma io credo che sia nato attorno al
fatto che esisteva assert, piuttosto che attorno al fatto che era la
semantica giusta.

Considera un test case in cui devo testare che un array non sia NULL e
> che contenga una serie di caratteri.
> Se il test assert p != NULL fallisce, il test case *deve* essere terminato.
>

Si. E viceversa se hai un oggetto di cui vuoi testare piu' proprieta' (cosa
di per se lecita: stai semplicemente controllando lo stato di *un* singolo
oggetto che e' l'output del SUT e semplicemente lo stato e' accessibile
tramite piu' proprieta') la cosa diventa scomoda. Diventa scomoda anche in
presenza dei "parametrized tests".

Entrambi gli approcci hanno vantaggi e svantaggi. A mio avviso la semantica
che non lancia l'eccezione e' complessivamente piu' flessibile (ovvero e'
meno pesante modellare la semantica in cui fermi il test sulla base di una
primitiva che di per se non lo ferma rispetto che il viceversa).

Non a caso in Go hai anche FailNow/Fatal* che hanno il comportamento di
fermare il test. Per cui semplicemente scrivi la cosa piu' coincisa
possibile a seconda di quello che vuoi fare.

Tempo fa avevo sviluppato una libreria per l'unit testing in C (oddio,
> quanto codice ho che non ho mai publicato...).
> La libreria usa il protocollo TAP, eppure avevo deciso di interrompere
> l'esecuzione della funzione di test
> in caso di fallimento, anche se non necessario (usando longjmp),
> perchè mi sembrava la scelta più ragionevole.
>

Eh... come dicevo, fanno tutti cosi', e' sensato farlo anche solo per
semplificare il ragionamento ai tuoi utenti.
Sebbene, a mio avviso, ancora una volta Go rompe gli schemi per fare la
cosa giusta.


>
> Non so perchè ero convinto che il test fosse interrotto in caso di
> fallimento, anche se la documentazione
> è chiara.
>
>
Ci sono anche funzioni che ti danno questa semantica. Semplicemente scegli
quello che ti serve.
Magari eri abituato ad usare quelle e non ti eri guardato quelle altre.


-- 
.
..: -enrico-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] pytest e classi

[enrico franchi]

2015-10-28 14:42 GMT+00:00 Manlio Perillo :

> Si, alla fine credo sia la cosa migliore, eseguendo il codice in un
> processo separato come suggerisci.
> Magari se ho tempo lo implemento per la mia libreria, anche se
> probabilmente non la userò molto.
> Forse usando fork/vfork (e ignorando Windows) si riesce a fare anche
> in modo abbastanza semplice,
>

Non vuoi usare vfork. Su un processo piccolo (come dovrebbe essere il
runner dei test) la differenza di performance sara' 10-20% in favore di
vfork.

Il problema e' che vfork e' veramente bislacca come semantica. Tipo il
fatto che vfork ti sospende il parent finche' il child non ha fatto exec
probabilmente non e' quello che vuoi. C'e' caso che quello che guadagni in
termini di performance, lo perdi perche' il parent nel frattempo deve
aspettare a fare qualunque cosa.

Il pezzo pero' piu' fastidioso della semantica di vfork e' che qualunque
cosa tu faccia fra vfork e exec nel figlio -- ovviamente, visto che il
padre e' stoppato -- si riflette nel padre. Il che puo' essere o meno
quello che vuoi. Io non sono sicuro se fare affidamento su questo
comportamento specifico per creare il tutto sia una buona idea. Se invece
uno non lo vuole esplicitamente, secondo me e' solo una potenziale fonte di
bachi.

Aggiuntivamente non e' necessario che il modello migliore passi per exec.
Potrebbe essere piu' conveniente fare semplicemente fork (un sacco di IPC
e' piu' comoda) ed eseguire il codice del test.

Viceversa, se usi direttamente clone con opzioni opportune potresti essere
30 volte piu' veloce (sia di fork che di vfork).
Allora per prendersi lo sbatti di usare qualcosa che non e' fork, un 30x
magari vale la pena... il 20% sulla syscall, che mi aspetto sia comunque
relativamente trascurabile rispetto al tempo di tirare su il test,
eseguirlo e poi eventualmente raccogliere statistiche e simili, secondo me
non vale la pena.



-- 
.
..: -enrico-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] pytest e classi

[Perini Matteo]

Il 26/10/2015 21:31, Manlio Perillo ha scritto:

Un ultimo consiglio.
Per testare funzioni come somma di solito è preferibile usare una
tabella con l'input e l'output corretto; ad esempio:

Fatto! grazie

Ora però ho un altro problema che non riesco a risolvere.
Riporto l'esempio di prima con il nuovo problema.

#!/usr/bin/env python3
# -*- coding: utf-8 -*-

class CC():
def __init__(self):
self.a = 2
self.b = 4
self.c = 5
def menouno(self,x):
return x-1
def somma(self):
return self.menouno(self.a+self.b+self.c)


if __name__=="__main__":
tt=CC()
print(tt.somma())

la somma in questo caso fa 10

Il mio file di test ora è così:

from pt import CC

def test_somma():
CC.__init__(CC)
assert CC.somma(CC)==10

Ma in questo caso self.menouno da errore perchè riceve un solo parametro 
(dice che manca la x)


Se nel file metto "return self.menouno(self, self.a+self.b+self.c)" 
viene eseguito il test ma non va più il programma e viceversa!


Ho cercato nella documentazione ma non ho ancora trovato una soluzione.

Grazie per l'aiuto
M.






___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] pytest e classi

[Manlio Perillo]

On Tue, Oct 27, 2015 at 1:47 PM, enrico franchi
 wrote:
>
> 2015-10-26 19:31 GMT+00:00 Manlio Perillo :
>>
>> Per testare funzioni come somma di solito è preferibile usare una
>> tabella con l'input e l'output corretto; ad esempio:
>>
>> table = [ ((1, 2, 3), 5), ((3, 5, 7), 15), ...]
>>
>> def test_somma():
>> for in, out in table:
>> cc = CC(*in)
>> assert cc.somma() == out
>>
>> CC(*in) è equivalente a CC(in[0], in[1], in[2]).
>
>
> Uhm... no. Questo e' un noto anti-pattern nel testing. Non si deve *mai*
> fare qualcosa del genere (a meno di non avere a che fare con un framework di
> test veramente primitivo).
>

> [...]

Bello, non lo conoscevo; grazie.
In effetti io uso solo unittest standard.

> http://xunitpatterns.com/Parameterized%20Test.html
>
> """
> Several early reviewers wrote to me about a variation they use regularly:
> the Tabular Test. The essence of this is the same as doing a Parameterized
> Test except that the entire table of values is in a single Test Method.
> Unfortunately, this makes the test an Eager Test (see Assertion Roulette on
> page X) because it verifies many test conditions. This isn't a problem when
> all the tests are passing but it does lead to a lack of Defect Localization
> (see Goals of Test Automation) when one of the rows fails.
> """

La libreria standard di Go usa questo metodo, ed in effetti può essere
visto come un problema.


Ciao  Manlio
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] pytest e classi

[simozack]

Il giorno 27 ottobre 2015 11:47, Perini Matteo  ha
scritto:

> from pt import CC
>
> def test_somma():
> CC.__init__(CC)
> assert CC.somma(CC)==10


Occhio che anche il test deve essere codice Python buono! :)

Prova, ad esempio, a creare all'interno di test_somma una istanza valida di
CC e di fare l'assert su quella.

Ciao,
Simone
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] pytest e classi

[Perini Matteo]

Il 27/10/2015 13:40, Manlio Perillo ha scritto:

Ti ho detto che non devi usare la classe in questo modo!
https://docs.python.org/2/tutorial

La classe la devi*instanziare*.

Pian piano si impara
Grazie dell'aiuto
M
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] pytest e classi

[Manlio Perillo]

2015-10-27 11:47 GMT+01:00 Perini Matteo :
> Il 26/10/2015 21:31, Manlio Perillo ha scritto:
>>
> [...]
> class CC():
> def __init__(self):
> self.a = 2
> self.b = 4
> self.c = 5
> def menouno(self,x):
> return x-1
> def somma(self):
> return self.menouno(self.a+self.b+self.c)
>
> [...]
>
> from pt import CC
>
> def test_somma():
> CC.__init__(CC)
> assert CC.somma(CC)==10
>

Ti ho detto che non devi usare la classe in questo modo!
https://docs.python.org/2/tutorial

La classe la devi *instanziare*.


Ciao  Manlio
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] pytest e classi

[enrico franchi]

2015-10-26 19:31 GMT+00:00 Manlio Perillo :

> Per testare funzioni come somma di solito è preferibile usare una
> tabella con l'input e l'output corretto; ad esempio:
>
> table = [ ((1, 2, 3), 5), ((3, 5, 7), 15), ...]
>
> def test_somma():
> for in, out in table:
> cc = CC(*in)
> assert cc.somma() == out
>
> CC(*in) è equivalente a CC(in[0], in[1], in[2]).
>

Uhm... no. Questo e' un noto anti-pattern nel testing. Non si deve *mai*
fare qualcosa del genere (a meno di non avere a che fare con un framework
di test veramente primitivo).

http://xunitpatterns.com/Parameterized%20Test.html

"""
Several early reviewers wrote to me about a variation they use regularly:
the *Tabular Test*. The essence of this is the same as doing a *Parameterized
Test* except that the entire table of values is in a single Test Method
. Unfortunately, this makes
the test an *Eager Test*
 (see
Assertion Roulette on page X) because it verifies many test conditions
. This isn't a problem when
all the tests are passing but it does lead to a lack of Defect Localization
 (see Goals of Test Automation) when one of the rows fails.
"""

Se si usa Nose:
https://nose.readthedocs.org/en/latest/writing_tests.html#test-generators

Se si usa PyTest:
https://pytest.org/latest/parametrize.html

-- 
.
..: -enrico-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] pytest e classi

[enrico franchi]

On Tue, Oct 27, 2015 at 1:30 PM, Manlio Perillo 
wrote:

>
> Bello, non lo conoscevo; grazie.
> In effetti io uso solo unittest standard.
>

https://github.com/rik0/ParamUnittest

Feel free to contribute.

Che io sappia ci sono solo un paio di magagne se hai ereditarieta'
complicata nei TestCase.


>
> La libreria standard di Go usa questo metodo, ed in effetti può essere
> visto come un problema.


In realta' non lo e'. Il punto e' che tutto questo discorso dei test e'
nato attorno ad una primitiva come assert che quando hai un problema
essenzialmente interrompe l'esecuzione li (tipicamente tirando
un'eccezione) e quindi le asserzioni successive non vengono eseguite.

La semantica dei test di Go invece e' basata attorno a primitive che
marcano il test fallito, ma proseguono con l'esecuzione. Quindi, di fatto,
buona parte dei problemi non ci sono piu'.
Personalmente la trovo una scelta eccellente, visto che e' molto piu'
facile da usare e di default porta meno problemi di assert.


-- 
.
..: -enrico-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] pytest e classi

[Manlio Perillo]

2015-10-27 15:51 GMT+01:00 enrico franchi :
> [...]
>> La libreria standard di Go usa questo metodo, ed in effetti può essere
>> visto come un problema.
>
>
> In realta' non lo e'. Il punto e' che tutto questo discorso dei test e' nato
> attorno ad una primitiva come assert che quando hai un problema
> essenzialmente interrompe l'esecuzione li (tipicamente tirando un'eccezione)
> e quindi le asserzioni successive non vengono eseguite.
>

Questo comportamento non è del tutto irragionevole.
Considera un test case in cui devo testare che un array non sia NULL e
che contenga una serie di caratteri.
Se il test assert p != NULL fallisce, il test case *deve* essere terminato.

Tempo fa avevo sviluppato una libreria per l'unit testing in C (oddio,
quanto codice ho che non ho mai publicato...).
La libreria usa il protocollo TAP, eppure avevo deciso di interrompere
l'esecuzione della funzione di test
in caso di fallimento, anche se non necessario (usando longjmp),
perchè mi sembrava la scelta più ragionevole.

> La semantica dei test di Go invece e' basata attorno a primitive che marcano
> il test fallito, ma proseguono con l'esecuzione. Quindi, di fatto, buona
> parte dei problemi non ci sono piu'.
> Personalmente la trovo una scelta eccellente, visto che e' molto piu' facile
> da usare e di default porta meno problemi di assert.
>

Non so perchè ero convinto che il test fosse interrotto in caso di
fallimento, anche se la documentazione
è chiara.


Ciao  Manlio
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] pytest e classi

[Manlio Perillo]

2015-10-26 20:02 GMT+01:00 Perini Matteo :
> Il 26/10/2015 20:02, Manlio Perillo ha scritto:
> [...]
>>
>> E' l'unico modo di fare unit test.
>> Il problema è che quel codice è sbagliato; non è il modo corretto di
>> usare le classi!
>>
>> Il modo corretto è:
>>
>> def test_somma():
>>  cc = CC(2, 4, 5)
>>  assert cc.somma() == 11
>>
> Chiaro!
> Grazie
>

Un ultimo consiglio.
Per testare funzioni come somma di solito è preferibile usare una
tabella con l'input e l'output corretto; ad esempio:

table = [ ((1, 2, 3), 5), ((3, 5, 7), 15), ...]

def test_somma():
for in, out in table:
cc = CC(*in)
assert cc.somma() == out

CC(*in) è equivalente a CC(in[0], in[1], in[2]).


Ciao  Manlio
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] pytest e classi

[Perini Matteo]

Il 26/10/2015 20:02, Manlio Perillo ha scritto:

test_somma **non** va messo nel modulo principale, ma nel modulo di test.
Ovvio che non lo trova.
Laggi la documentazione di pytest per vedere come vengono trovate le
funzioni di test.

OK!

E' l'unico modo di fare unit test.
Il problema è che quel codice è sbagliato; non è il modo corretto di
usare le classi!

Il modo corretto è:

def test_somma():
 cc = CC(2, 4, 5)
 assert cc.somma() == 11


Chiaro!
Grazie
M.

___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] pytest e classi

[Perini Matteo]

Il 26/10/2015 18:56, Manlio Perillo ha scritto:

Io non vedo il senso di quello che vuoi fare...

Ok scusate... forse riesco a chiarire!

se ho questo codice (pt.py):

#!/usr/bin/env python3
# -*- coding: utf-8 -*-

import numpy as np

def plusone(x):
return x+1

class CC():
def __init__(self):
self.a = 2
self.b = 4
self.c = 5

def somma(self):
return  self.a+self.b+self.c
def test_somma():
assert somma()==11

if __name__=="__main__":
tt=CC()
print(tt.somma())


se do il comando:
py.test-3 pt.py

pytest non trova nessun test da fare!
se richiamo il test da un file esterno (test_pt.py) in questo modo:

from pt import CC

def test_somma():
CC.a=2
CC.b=4
CC.c=5
assert CC.somma(CC)==11

il test funziona.

Ma è il modo giusto di passare i parametri alla funzione di test?

Spero di non aver fatto ulteriore confusione!
Grazie
Ciao
M.

___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] pytest e classi

[Daniele Zambelli]

Il 26 ottobre 2015 18:39, Perini Matteo  ha scritto:

Ciao.

Forse sarebbe più sensato, al posto di:

> class CC():
> def __init__(self):
> self.a = 2
> self.b = 4
> self.c = 5

definire __init__ in questo modo:

 def __init__(self, a, b, c):
 self.a = a
 self.b = b
 self.c = c

E poi nella funzione test_somma:

def test_somma():
tt = CC(2, 4, 5)
assert tt.somma()==11

Ciao

-- 

Daniele

www.fugamatematica.blogspot.com

giusto!
nel verso
forse è perché non guardiamo le cose
Quando non ci capiamo,
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] pytest e classi

[Manlio Perillo]

2015-10-26 18:39 GMT+01:00 Perini Matteo :
> Il 26/10/2015 18:56, Manlio Perillo ha scritto:
> [...]
> class CC():
> def __init__(self):
> self.a = 2
> self.b = 4
> self.c = 5
>
> def somma(self):
> return  self.a+self.b+self.c
> def test_somma():
> assert somma()==11
>

test_somma **non** va messo nel modulo principale, ma nel modulo di test.

> if __name__=="__main__":
> tt=CC()
> print(tt.somma())
>
>
> se do il comando:
> py.test-3 pt.py
>
> pytest non trova nessun test da fare!

Ovvio che non lo trova.
Laggi la documentazione di pytest per vedere come vengono trovate le
funzioni di test.

> se richiamo il test da un file esterno (test_pt.py) in questo modo:
>
> from pt import CC
>
> def test_somma():
> CC.a=2
> CC.b=4
> CC.c=5
> assert CC.somma(CC)==11
>
> il test funziona.
>
> Ma è il modo giusto di passare i parametri alla funzione di test?

E' l'unico modo di fare unit test.
Il problema è che quel codice è sbagliato; non è il modo corretto di
usare le classi!

Il modo corretto è:

def test_somma():
cc = CC(2, 4, 5)
assert cc.somma() == 11


Ciao  Manlio
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] pytest e classi

[Manlio Perillo]

2015-10-26 17:32 GMT+01:00 Perini Matteo :
> Ciao,
> sto iniziando ad usare pytest.
> Probabilmente mi sto perdendo in un bicchier d'acqua ma ho grossi problemi
> con il passaggio di parametri alle funzioni di test.
> Faccio un esempio che forse è più facile
>
> Ipotizziamo un file (xxx.py) fatto così:
>
> #!/usr/bin/env python3
> # -*- coding: utf-8 -*-
>
> import numpy as np
>
> def plusone(x):
> return x+1
>
> class CC():
> self.a = 2
> self.b = 4
> self.c = 5
>
> def somma(self):
> return  self.a+self.b+self.c
>
>somma()

L'indentazione non è corretta; cosa stai facendo esattamente?

>
> ---
> Come faccio a testare la funzione somma?

Scrivi una funzione di test, tipo `test_somma`, e chiami la funzione
somma con diversi parametri di input e controlli
che l'output sia corretto.

> L'unico modo che ho trovato è stato quello di cambiare la funzione della
> classe così:
>
> def somma(self,a,b,c):
> self.a=a
> self.b=b
> self.c=c
> return  self.a+self.b+self.c
>somma(CC,self.a,self.b,self.c)
>
> ma mi sembra una complicazione inutile.

Io non vedo il senso di quello che vuoi fare...

>
> Ho un file esterno per richiamare tutti i test_xxx.py fatto così:
>
> from xxx import *
> from xxx import CC
>
>
> def test_somma():
> assert somma(2,3,3)==8
>
>
> Il test funziona ma non mi sembra proprio il modo giusto di operare
>

È l'unico modo.
Ah, e **cerca** di evitare * nell'import.


Ciao  Manlio
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

[Python] pytest e classi

[Perini Matteo]

Ciao,
sto iniziando ad usare pytest.
Probabilmente mi sto perdendo in un bicchier d'acqua ma ho grossi 
problemi con il passaggio di parametri alle funzioni di test.

Faccio un esempio che forse è più facile

Ipotizziamo un file (xxx.py) fatto così:

#!/usr/bin/env python3
# -*- coding: utf-8 -*-

import numpy as np

def plusone(x):
return x+1

class CC():
self.a = 2
self.b = 4
self.c = 5

def somma(self):
return  self.a+self.b+self.c

   somma()

---
Come faccio a testare la funzione somma?
L'unico modo che ho trovato è stato quello di cambiare la funzione della 
classe così:


def somma(self,a,b,c):
self.a=a
self.b=b
self.c=c
return  self.a+self.b+self.c
   somma(CC,self.a,self.b,self.c)

ma mi sembra una complicazione inutile.

Ho un file esterno per richiamare tutti i test_xxx.py fatto così:

from xxx import *
from xxx import CC


def test_somma():
assert somma(2,3,3)==8


Il test funziona ma non mi sembra proprio il modo giusto di operare

Potreste darmi qualche dritta  su come fareste voi?
Come posso testare la funzione somma come scritta nel file originale?
Grazie
Ciao
Matteo




___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python