[Python] doctest con funzioni che aprono files

[Giovanni Marco Dall'Olio]

2008/11/26 Daniele Varrazzo <piro a develer.com>:
>
>
> On Wed, 26 Nov 2008 17:44:55 +0100, "Giovanni Marco Dall'Olio"
> <dalloliogm a gmail.com> wrote:
>> Ciao a tutti,
>> e' da un po' di tempo che utilizzo doctest, e sono felice :).
>>
>> Lo trovo molto comodo per scrivere funzioni che calcolano statistiche
>> e parsano particolari formati di files.
>>
>> Quello che non capisco ancora e' come utilizzarlo per testare funzioni
>> che prendano in input il nome (path) di un file, e lo aprano.
>
> Tu sei sicuro che una docstring nella quale hai buttato dentro tutto il
> codice boilerplate per fargli aprire un file temporaneo abbia ancora una
> qualche utilità come docstring?

Per alcune cose che devo fare, si.
Sto contribuendo al progetto biopython, una collezione di moduli per
la bioinformatica in python.
Visto che questi moduli devono essere utilizzati da terze parti,
aggiungere un esempio del file di input nel doctest e' una cosa
utilissima.
In questo modo, un utente che si ritrovi a riutilizzare le mie
librerie, potra' avere una idea chiara del formato per il quale un
modulo e' stato scritto (pensa soprattutto a quando devi parsare un
particolare formato di testo).

Qualche settimana fa ho scritto un post sul mio blog per spiegare
questo; vedi se l'esempio puo' essere piu' chiaro:
- http://bioinfoblog.it/2008/11/biopython-e-doctest/
In questi giorni sto scrivendo molti parsers cosi':
- http://github.com/dalloliogm/biopython---popgen/tree/master/src%2FPopGen%2FGio%2FfastPhaseOutputIO.py

>
> È una mia idea personale, ma le doctest a me sembrano innanzitutto "doc",
> e solo come cosa secondaria e pythonesca "test". In particolar modo, è
> più un test della documentazione stessa che della funzione. Ma questo può
> ovviamente essere stiracchiato un pochino, e quindi il test, come effetto
> collaterale, testa che la funzione non cominci a sbagliare. Stiracchiando
> stiracchiando però aggiungi "documentazione" utile ai fini del test e non
> ai fini della documentazione, fino al punto che non è più documentazione
> in lingua umana, ma codice Python che descrive codice Python.

In parte si'. Te lo posso confermare, perche' ultimamente ho scritto
dei doctest enormi.
Pero', se scrivi la doctest ancora prima del codice, poi viene molto
piu' facile scrivere il resto (beh, questo e' vero con tutti i test).

> È sempre una mia opinione personale, ma mi sembra che le doctest non
> vogliano essere questo, al punto che non offrono nessuna facility di
> costruzione di "test suite". A me sembra che quello che tu stia facendo sia
> una unit test completa, che ha bisogno di dati di appoggio ed eventualmente
> funzioni di setup e cleanup.

In parte si, e comunque li puoi integrare con unittest (doctest.DocTestSuite)


>> Una seconda opzione e' quella di usare tempfile.NamedTemporaryFile.
>> Il problema e' che e' una opzione un poco brutta esteticamente, che
>> aggiunge un sacco di istruzioni non necessarie nella documentazione
>> (incasinandola).
>
> Questo è quello che farei io, ma in una test suite. Questo credo sia il
> punto dove la doctest smette di essere "bella" (documentazione che come
> effetto collaterale si auto-testa) e diventa "brutta" (codice di test
> scritto dove sarebbe dovuta andare la documentazione).

come dicevo prima, se devi scrivere del codice riutilizzabile da altre
persone, la doctest e' utile.
E' molto comoda anche se stai lavorando al fianco di persone che non
sanno molto di programmazione, e vuoi farli capire esattamente cosa
verra' fuori nei risultati. Ho dei buoni esempi su questo, ma ora non
ho il tempo di caricarli :)

> Puoi avere tutti e due, unittest e doctest non sono esclusive. Penso che le
> doctest siano una bella abitudine: fossi in te sceglierei pragmaticamente
> "il meglio dei due mondi" :)

Certamente, anche se devo ammettere di non aver usato molto unittest.


> --
> Daniele Varrazzo - Develer S.r.l.
> http://www.develer.com
>



-- 

My blog on bioinformatics (now in English): http://bioinfoblog.it