Come posso testare un involucro gestito attorno al codice C?

Question

Creerò un wrapper Managed-C++ attorno ad alcune funzioni C per consentirne l'utilizzo in altre soluzioni .NET. Sto cercando di fornire un wrapper molto minimalista, qualcosa come:

Firma nell'intestazione C:

void DOSTH(const char*, short, long*); 

Exposed interfaccia gestita:

public void doSomething(String^ input, short param, [Out] long^ %result); 

Per fare ciò la mia soluzione avrà la C le intestazioni e faranno riferimento al file .dll che contiene l'API C compilata che sto costruendo contro.

Come un principiante di Visual Studio non sono sicuro di come testare l'unità. È possibile prendere in giro la .dll per fornire un'implementazione fittizia? C'è una biblioteca che renderebbe questo tipo di compito facile? C'è una particolare struttura di soluzione che dovrei cercare di semplificare?

Qualsiasi guida in questo settore sarebbe eccezionale. Le ricerche su Google mi hanno lasciato alla ricerca di maggiori informazioni sull'unità che testava un wrapper gestito.

Answer 1

Hai solo bisogno di essere in grado di bloccare/deridere il tuo wrapper in modo che i tuoi test non si basino sulla dll nativa?

Quindi è possibile dichiarare una classe base astratta per il proprio wrapper, scrivere un'implementazione che chiama la DLL nativa e un'altra a scopo di test che restituisce valori predefiniti. Oppure puoi usare un framework come Moq o Rhino.Mocks per prendere in giro il tuo wrapper.

Answer 2

In alcuni casi (mi viene in mente la limitazione degli strumenti e/o la dipendenza), è fuori discussione la dipendenza derisoria che utilizza i framework esterni. Quindi, c'è una tecnica totalmente legittima di scrivere manualmente i mock (penso che il fosse il modo di fare cose prima che le strutture di simulazione diventassero popolari).

E questo è fondamentalmente quello che si vuole fare - dipendenza da falso, che nel tuo caso sembra essere la libreria C. I framework non possono essere d'aiuto: potresti voler provare l'approccio manuale.

Creare un'implementazione semplice e fittizia (molto simile a uno stub, ad esempio solo restituire valori fissi indipendentemente dai parametri di input - naturalmente, potrebbe essere più sofisticato di quello), compilarlo, lasciare esporre esattamente le stesse intestazioni/funzioni e facci riferimento nel tuo progetto di test. Questa è l'idea essenziale alla base del falso (stubbing/beffardo) - un oggetto che finge di essere un altro.

Per quanto semplice possa sembrare, non l'ho ancora provato - prendilo con un pizzico di sale e altro come suggerimento su quale strada potresti andare. La limitazione di questo approccio (a prescindere dal fatto che sia effettivamente possibile tecnicamente) è molto povera/nessuna delle opzioni di configurazione (poiché la DLL falsata in più si comporta come uno stub codificato - i file di configurazione potrebbero aiutare, ma sembra ... troppo lavoro?).