Come organizzare le mie funzioni di test?

1

Sto scrivendo un'applicazione software di qualche migliaio di righe di codice (in Python), e al fine di mantenere il tutto insieme, lentamente ma certamente la necessità di test unitari (e successivamente, altri tipi di test .. .) è sorto.

Il mio problema è come organizzare le numerose funzioni di test che ho scritto finora: Supponiamo che abbia una funzione myfunc per cui voglio scrivere test. Quello che ho sono funzioni in questo modo:

test1pos_myfunc():
    #...

test2pos_myfunc():
    #...

test3pos_myfunc():
    #...

#and so on...

che testano ciascuno se un input se myfunc fornisce l'output corretto. Poi ho anche un'altra suite di funzioni dove cerco dove vengono lanciate le eccezioni corrette se fornisco input non validi a myfunc ; questi sono

test1neg_myfunc():
    #...

test2neg_myfunc():
    #...

test3neg_myfunc():
    #...

#and so on...

Questa configurazione sembra non ideale, in particolare per i test "negativi", perché spesso raggruppo insieme quelle funzioni che testano se viene lanciata la stessa eccezione - ad es. test1neg_myfunc , test2neg_myfunc e test3neg_myfunc potrebbero testare tutti se la stessa eccezione MyError viene generata per input diversi e test4neg_myfunc e test5neg_myfunc potrebbero verificare se viene generata la stessa MyHorribbleError .

Ora, se voglio aggiungere un'altra funzione di test per testare'MyError ', devo rinumerare tutte le altre funzioni. Quale sarebbe un modo migliore per organizzare questo?

Ecco alcune soluzioni che ho pensato, ma nessuna mi soddisfa:

  • usa il nome dell'eccezione nel nome della funzione e riavvia la numerazione per ogni test di una nuova eccezione (sembra una cattiva idea, perché ridurrà la leggibilità), ad es. test1MyError_myfunc , test2MyError_myfunc e così via.

  • prendere tutti i test di un'eccezione e raggrupparli come metodi in una classe; e poi anche tutti i test che appartengono ad una funzione in una classe (questo è meglio che i miei nomi di test diventino più brevi e - ma poi di nuovo ci si sente male, perché sto importando un concetto da OOP in un ambiente in cui sto programmando rigorosamente procedurale! E usando una classe solo per raggruppare insieme alcune funzioni sembra eccessivo, Python non offre qualcosa di meglio come contenitore per memorizzare altre cose?)

  • esternalizzare tutti i test, simili all'organizzazione in classi, in diversi moduli (tutto ciò che ho scritto sulle classi si applica, ma con l'enorme svantaggio che avrò una tonnellata di file poi in giro)

Qualcuno può inventarsi qualcosa di meglio? Quali sono gli standard industriali qui? (Sono un programmatore alle prime armi.)

    
posta l7ll7 16.12.2018 - 10:54
fonte

1 risposta

4

In generale dovresti essere in grado di capire cosa fa / controlla un test solo guardando il suo nome. Ciò significa che dovresti dare ai tuoi test nomi espressivi. Ciò potrebbe includere anche nomi molto lunghi che in genere non vengono utilizzati nel codice di produzione. Uno schema di denominazione comune è correlato al Meszaros schema di prova a quattro fasi (Disporre, Agire, Asserire, Annientare). Questo significa che il test è composto da quattro parti. Nella prima parte si "organizza" il dispositivo di test configurando l'oggetto che si desidera testare (System Under Test / "SUT"). Nella seconda parte dichiari al SUT di "agire" chiamando un metodo e nella terza fase "asserisci" verifichi le tue aspettative. Le tre fasi possono anche essere riflesse nel nome del metodo di prova. Spesso trovi nomi che leggono come Given_When_Then .

Nella fase "Annientamento" di solito abbatti oggetti creati dinamicamente usati nel test. Lo troverai principalmente se devi eseguire manualmente la gestione della memoria.

Per favore, sappi anche che i tuoi test unitari dovrebbero essere indipendenti l'uno dall'altro. Ciò significa che i tuoi test possono essere eseguiti in qualsiasi ordine. La numerazione dei test suggerisce che dovrebbero essere eseguiti in un certo ordine.

    
risposta data 16.12.2018 - 11:29
fonte

Leggi altre domande sui tag