Come distingui le tue interfacce API pubbliche dalle interfacce che usi per test / mocking?

-2

I framework di simulazione sono utili per creare oggetti mock che isolano il codice sottoposto a test dall'ambiente software circostante. Alcuni framework di derisione non possono prendere in giro metodi non virtuali, quindi richiedono di creare un Interface per ogni classe, se non si desidera rendere i metodi virtual .

Come distingui queste interfacce da quelle "reali"? Cioè, se hai un'API pubblica, dai il nome alle interfacce che vuoi che il tuo cliente usi qualcos'altro, o nascondi le interfacce di test in un assembly o spazio dei nomi separato?

Per inciso, è davvero necessario creare tutte quelle interfacce? Non mi piace l'idea di rendere tutti i miei metodi virtual , ma io veramente non mi piace l'idea di creare tante interfacce solo per renderle accessibili a un sistema di simulazione.

    
posta Robert Harvey 31.05.2013 - 00:49
fonte

1 risposta

2

Io no.

O la classe è (effettivamente) sealed / final o ha un'interfaccia. Non compro tutte le classi interne sono in qualche modo al di sopra della legge: esiste l'astrazione per proteggerti dai cambiamenti e i tuoi tipi interni hanno le stesse probabilità di cambiamento.

Le strutture di base (DTO, tuple e altri oggetti solitamente sigillati / finali) vanno bene per la mia esperienza da usare come nei test. Sono effettivamente parte dell'interfaccia pubblica dei tuoi moduli.

    
risposta data 31.05.2013 - 01:04
fonte

Leggi altre domande sui tag