[Python] test [was: Re: Come fareste voi?]

Daniele Varrazzo piro a develer.com
Sab 20 Feb 2010 00:08:13 CET


On Fri, 19 Feb 2010 22:51:12 +0100, Alessandro Dentella <sandro a 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


Maggiori informazioni sulla lista Python