data-driven unit test con python e nose

un modo, molto potente, per controllare se un file che ci arriva in input è sia formalmente (riguardo alla "fisicità", la rappresentazione concreta dei dati che contiene) che semanticamente (riguardo al "significato" logico dei dati che contiene) corretto consiste nel metterlo sotto unit testing - di controllarlo cioè con un programma diagnostico che ne analizzi i contenuti eseguendo test sistematici. in questo modo ogni volta che riceveremo un file di contenuto analogo potremo verificarne la correttezza automagicamente.

se i dati sono suddivisibili per riga, cioè ogni riga nel file è l'espressione compiuta di quello che ci interessa, tutto si riduce a fare una serie di controlli - virtualmente sempre gli stessi - per ogni riga del file; in questo caso possiamo ricorrere al DDUT (data-driven unit testing) dove i test sono appunto innescati dalla singola riga della struttura dati che guida l'elaborazione, nel nostro caso il file in input.

In pratica, con python e nose (un framework di automazione per i test) , il procedimento è semplicissimo: prendiamo ad esempio un piccolo file di dati, mydata.txt (in ambiente windows, dove il separatore di riga è tradizionalmente lo "\r\n")


0123456789
0123456
0123456789   
01234567890123456789
0123456789


dove ci piacerebbe essere certi (esempio di verifica formale) che tutte le righe siano lunghe 10: la classe di test che ci aiuta a fare tutto questo è molto semplice.


class Test_DataDriven():

    @classmethod
    def setupClass(self):
        self.infile = open("mydata.txt", "rb")

    @classmethod
    def teardownClass(self):
        self.infile.close()
    
    def test_datarow(self):
        for row in self.infile:
            yield self.check_rowlen, row.rstrip("\r\n")

    def check_rowlen(self, arow): 
        assert len(arow) == 10


cosa succede: entra in azione nosetests - una tantum (nella setupClass) il file-guida viene aperto e per ogni sua riga (in test_datarow) viene richiamato il controllo di lunghezza (test_datarow genera infatti il test implementato poi in check_rowlen). il file viene poi chiuso alla fine di tutti i test (tearDown). il framework nose, che qui interviene con il programma driver nosetests eseguito sui test d'esempio, usa un sistema di convenzioni sui nomi delle classi e dei metodi per capire cosa fare.

come quasi ogni esempio didattico è decisamente sovrastrutturale rispetto al risultato, ma l'impostazione permette di essere estesa elegantemente a controlli di ben altra complessità.