È buona norma fornire interfacce in una libreria che verrebbe utilizzata solo per il test delle unità?

Question

È buona norma fornire interfacce in una libreria che verrebbe utilizzata solo per il test delle unità?

#1 da (3 voti)
#2 da (3 voti)

1

Domanda spontanea: Qual è il motivo della progettazione per cui una classe di libreria non implementerebbe un'interfaccia come vantaggio per lo sviluppatore? (ad es., la classe della libreria .Net FileInfo )

La classe FileInfo dipende necessariamente dal file system. Questo ovviamente presenta problemi durante i test unitari. Se dovessi progettare e implementare questa classe per il mio uso interno, risolverei il problema implementando FileInfo come IFileInfo corrispondente. Quindi posso iniettare la dipendenza di IFileInfo comunque voglio e codice dipendente da test di unità facilmente.

Ma non implemento FileInfo da solo, l'ho preso da una terza parte, quindi devo creare un'interfaccia, una classe di wrapping e in qualche modo stub o mock quell'interfaccia per ottenere un risultato simile.

Mi sembra che fornire l'interfaccia come parte della libreria sia un modo ponderato per rendere la vita del futuro sviluppatore più facile e il loro codice più facile da mantenere.

Sarebbe un modo accettabile per progettare una biblioteca, perché o perché?

unit-testing api libraries

posta etberg 10.10.2018 - 20:16

fonte

2 risposte

Leggi altre domande sui tag unit-testing api libraries

Metodi di classe che non vengono mai chiamati e tutto gestito dagli interni della classe stessa Trattare con i modelli di dominio in continua crescita

score 3 · Answer 1

Un'interpretazione interessante di ciò deriva dal considerare ciò che abbiamo appreso dei moduli da Parnas . Se i moduli sono progettati per essere dei limiti decisionali e la scelta di soddisfare i nostri requisiti tramite FileInfo è una decisione che stiamo prendendo, allora ci dovrebbe essere un piccolo modulo di confine attorno a tale decisione.

Quindi l'interfaccia che vogliamo testare è il modulo boundary, non FileInfo.

L'odore del codice che stai ottenendo dal tuo test forse dovrebbe sfidare la scelta di esporre FileInfo nella tua API.

score 3 · Answer 2

Una cosa da tenere a mente con FileInfo è che si tratta sia di un oggetto dati sia di un servizio in uno.

Per gli oggetti, normalmente non creerei interfacce (la ragione principale per cui creo un'interfaccia per gli oggetti dati è principalmente quella di consentire una versione readonly di esso).

I servizi che vuoi essere in grado di eseguire lo stub richiedono un'interfaccia.

Se dipendesse da me, non userei FileInfo come hai descritto. Lo separerei in un oggetto e un servizio come 2 concetti separati. Inietta il servizio nelle classi che devono agire sull'oggetto, dove l'oggetto può essere solo una stringa (il percorso file).

Basta passare il filepath come stringa attorno e inviarlo al tuo servizio ogni volta che vuoi operare sul percorso file stesso.