Re: [Python] test [was: Re: Come fareste voi?]
Sono anche convinto che la flessibilità delle unittest (o simili) sia molto maggiore in varie circostanze per cui non ci rinuncerei affatto. Non ho intenzione di farti cambiare idea: visto che lo strumento è stato citato, queste sono le mie considerazioni e i motivi per cui io non le uso se non per testare documentazione. Secondo me la documentazione deve essere esplicativa mentre i test devono essere esaustivi: visto i due obiettivi spesso finiscono con l'essere in contraddizione preferisco tenerli fisicamente separati e usare lo strumento migliore per l'obiettivo. non è che cerchi contrapposizione dove non c'è? Mi pare che le differenze fra il mio ed il tuo punti di vista siano relativamente piccole. La mia frase che cito era per confermare che anche io trovo una flessibilità maggiore in *unittest* e simili (nose, py.test migliorano in vario modo ma non stravolgono il concetto degli unittest) ed a questi non rinuncerei, ma non rinuncerei neanche ai doctest quando voglio qualcosa che assomigli di più alla documentazione. [Per inciso non metto i test nelle docstring ma in file separati, proprio perché son convinto che una docstring troppo lunga non sia comoda.] sandro *:-) ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] test [was: Re: Come fareste voi?]
On Sat, 20 Feb 2010 09:57:21 +0100, Alessandro Dentella san...@e-den.it wrote: non è che cerchi contrapposizione dove non c'è? Mi pare che le differenze fra il mio ed il tuo punti di vista siano relativamente piccole. Scusami, ero un po' lanciato ;) A presto, ciao! -- Daniele Varrazzo - Develer S.r.l. http://www.develer.com ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] test [was: Re: Come fareste voi?]
A me piacciono i doctest, ovviamente li uso giusto per metodi semplisiccimi, non devono superare le 4 righe :-D Simone Federici --- Software Architect 2010/2/20 Daniele Varrazzo p...@develer.com On Sat, 20 Feb 2010 09:57:21 +0100, Alessandro Dentella san...@e-den.it wrote: non è che cerchi contrapposizione dove non c'è? Mi pare che le differenze fra il mio ed il tuo punti di vista siano relativamente piccole. Scusami, ero un po' lanciato ;) A presto, ciao! -- Daniele Varrazzo - Develer S.r.l. http://www.develer.com ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
[Python] test [was: Re: Come fareste voi?]
On Fri, 19 Feb 2010 19:36:02 +0100, Alessandro Dentella san...@e-den.it wrote: O nose... io ultimamente lo apprezzo molto. In questa lista si è sponsorizzato a più riprese nose, qualcuno può dire come si confronta con py.test? Sono uguali: se ne usi uno difficilmente rimpiangi l'altro (secondo me). A me piaciono anche i doctest quando penso ai test come documentazione di API ma sia nose che py.test possono eseguire i test in formato doctest ma danno un sommario molto povero ovvero cosiderano un file.txt con dentro i test come un singolo test, quando il modulo doctest li considera sigolarmente. Inoltre io non sono riuscito ad usare in modo utile l'opzione per cui note/py.test aprono la shell di debug quando capita un errore, cosa che invece funziona bene sia con nose che con py.test con test di tipo unittest. Perché, e qui lo dichiaro pubblicamente, i doctest sono la tecnologia di test più abusata e meno adatta che sia venuto in mente a chiunque abbia visto un prompt fatto così: I doctest sono un brillante modo di testare... la documentazione!!! da quando sono diventati un modo di testare il programma? Purtroppo da abbastanza presto, e sono uno strumento oscenamente scomodo per farlo, nel senso che costringono a contorsioni da kamasutra per eliminare la variabilità che c'è nell'output dei comandi [1] o per mettere insieme una test suite con setup e teardown. In tutto questo le docstring perdono il significato originale: essere documentazione concisa. [1] http://docs.python.org/library/doctest.html#option-flags-and-directives Ed Loper, autore di Epydoc (credo anche uno degli autori di doctest), ha usato solo doctest per documentare Epydoc stesso [2]. Ma tu guarda che si è dovuto inventare [3] per far girare una test suite un po' più complessa?!?! Ne è valsa la pena? A me non sembra. [2] http://epydoc.svn.sourceforge.net/viewvc/epydoc/trunk/epydoc/src/epydoc/test/ [3] http://epydoc.svn.sourceforge.net/viewvc/epydoc/trunk/epydoc/src/epydoc/test/util.py?revision=1502view=markup Quindi per me SE uno scrive delle docstring e SE nelle docstring capita che ci sia un esempio autocontenuto (e non fetch restituisce un record: Record.fetch()... e poi serve un database e come configurare il DSN di test...) allora tu fai girare i doctest e verifichi che la docstring sia consistente con quello che dichiara. Che poi siano anche test aggiuntivi per la test suite completa del programma, tanto meglio. Ma che le docstring sostituiscano una unit test apposita, secondo me, è un giochino carino, divertente, ma durato troppo. -- Daniele Varrazzo - Develer S.r.l. http://www.develer.com ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] test [was: Re: Come fareste voi?]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Daniele Varrazzo ha scritto: [...] Inoltre io non sono riuscito ad usare in modo utile l'opzione per cui note/py.test aprono la shell di debug quando capita un errore, cosa che invece funziona bene sia con nose che con py.test con test di tipo unittest. Perché, e qui lo dichiaro pubblicamente, i doctest sono la tecnologia di test più abusata e meno adatta che sia venuto in mente a chiunque abbia visto un prompt fatto così: Concordo su tutto. Cominci ad usare una cosa perchè è comoda, e finisci con l'abusarne, insistendo anche quando perdi la comodità e l'espressività. Ciao Manlio -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkt+7h0ACgkQscQJ24LbaUS2OwCePgc1wlTLk8OrfI+3Xzty+Bfp ZBcAn3UBMMs7kkfRMpLJvFO5Bhic0D9l =/KF2 -END PGP SIGNATURE- ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] test [was: Re: Come fareste voi?]
On Fri, 19 Feb 2010 22:51:12 +0100, Alessandro Dentella san...@e-den.it wrote: 1. probabilmente anche in uno unittest avrebbero dovuto esserci delle test/helper function fatte per rendere i test più leggibili... Il fatto è che in una unit test le funzioni helper sono codice messo a fianco al codice, con funzioni che chiamano altre funzioni... normalissimo python, no? Una doctest è un'imbragatura sadomaso che costringe ad un'unica funzione di test, ovvero assert str(o) == s con s costante. Qualunque test lo devi ridurre a questo, tutti i metodi che ti aspetti in un framework di test suite ricco (es. assertAlmostEqual...) te lo scordi e devi sempre starti ad inventare un helper() per cui str(helper(o)) == s. Se anche devi mettere funzioni helper in una test suite, hanno la possibilità di lavorare su tipi di dati più ricchi, sfruttando tutto quello che offre il linguaggio, anziché rimpiazzare stringhe su stringhe fino a ridurre il risultato una costante da confrontare per eguaglianza col prototipo (ah, a meno di IGNORE_EXCEPTION_DETAIL e NORMALIZE_WHITESPACE... altre funzioni che trasformano testo in testo) 2. proprio perché ce ne è più di uno mi pare che sia corretto scegliere il migliore per ogni singola situazione. E` corretto chiedere che si evitino contorsionismi strani, ma spesso la leggibilità di test fatti con doctest è decisamente elevata. Già parlare di metodologie è soggettivo, parlare di leggibilità forse lo è anche di più... In ogni caso io definisco una docstring leggibile quando è documentazione leggibile, non quando è un test leggibile. E visto che i test *puoi* metterli altrove ma le docstring no, devono stare nel modulo, e visto che 500 righe di test ci stanno bene su un metodo di 10 righe, ma 500 righe di test in mezzo a metodi di 10 righe (e dico proprio *in mezzo*, tra un metodo e l'altro)... io le docstring non le ammiro. Sono anche convinto che la flessibilità delle unittest (o simili) sia molto maggiore in varie circostanze per cui non ci rinuncerei affatto. Non ho intenzione di farti cambiare idea: visto che lo strumento è stato citato, queste sono le mie considerazioni e i motivi per cui io non le uso se non per testare documentazione. Secondo me la documentazione deve essere esplicativa mentre i test devono essere esaustivi: visto i due obiettivi spesso finiscono con l'essere in contraddizione preferisco tenerli fisicamente separati e usare lo strumento migliore per l'obiettivo. -- Daniele Varrazzo - Develer S.r.l. http://www.develer.com ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
