Test di una classe con metodi "prerequisiti"

Question

Test di una classe con metodi "prerequisiti"

Naviga le tue risposte

#1 da (4 voti)

3

Sto lavorando su una classe che dovrebbe manipolare i file.

La sua interfaccia ha un metodo Open(string filename) e vari altri metodi per recuperare e manipolare il contenuto.

È corretto chiamare il metodo aperto prima di chiamare il metodo che sto provando a testare?

Da un lato, questo documenta il fatto che il metodo aperto dovrebbe essere chiamato prima di qualsiasi altro metodo.

D'altro canto, sono preoccupato dell'efficacia di tali test poiché, se il metodo Open smette di funzionare, tutti i test non riuscirebbero senza riportare in realtà un errore del metodo che dovrebbero testare.

Cose che ho considerato:

Usare la riflessione durante il test per mettere l'oggetto in uno stato "lavorabile" noto, senza chiamare il metodo aperto (complesso e difficile da mantenere)

Utilizzo di un metodo di costruzione statico che crea l'oggetto e quindi lo apre, restituendo l'oggetto di lavoro (ma dovrebbe esserci anche un'opzione per avere l'oggetto in uno stato "chiuso", inoltre ciò non evita di chiamare il metodo aperto , lo nasconde semplicemente)

unit-testing construction

posta BgrWorker 25.07.2016 - 11:52

fonte

1 risposta

Leggi altre domande sui tag unit-testing construction

dati facoltativi nel costruttore, cattiva pratica? interfacce fluenti, indipendenti dall'ordine;

score 4 · Answer 1

In base a ciò che descrivi, quindi, sì, è un male necessario chiamare il metodo open anche se, come dici tu, un errore di open mostrerà in modo inappropriato i guasti di tutti i test dipendenti.

Tuttavia, raccomanderei un approccio piuttosto diverso. Qualsiasi classe che deve andare su "bare metal" (cioè, toccare le risorse di sistema) dovrebbe sforzarsi di essere classi di soli conduttori, cioè fare il minimo assoluto per gestire la risorsa. Nella tua domanda fai effettivamente la chiara delineazione: i tuoi metodi "... recuperano e manipolano i contenuti." Quindi quello che sto suggerendo è che hai un FileSystemProvider per recuperare i contenuti e un FileSystemManipulator separato per manipolare i contenuti. Quest'ultimo prenderà un FileSystemProvider come una dipendenza iniettata, rendendo così un compito semplice prendere in giro un FileSystemProvider quando si esegue il test unitario FileSystemManipulator e si esegue il rendering della domanda.

Ovviamente, testare FileSystemProvider dovrà toccare i file reali, ma i suoi metodi dovrebbero essere così semplici e diretti da non aver quasi bisogno dei test unitari. (Si potrebbe sostenere che, in effetti, non sarebbero più essere test di unità perché toccano le risorse di sistema, ma sono quindi test di integrazione a livello di sviluppatore essere un po 'trascurati applicando le severe linee guida dei test unitari a loro.)