Durante la creazione di una libreria pubblicata su CodePlex, in che modo "cattivo" sarebbe possibile affidare i progetti di unit test ai prodotti commerciali?

3

Ho avviato un progetto su CodePlex per un'implementazione del server WebDAV per .NET, in modo da poter ospitare un server WebDAV nei miei programmi. Questo è sia un progetto di apprendimento / ricerca (parte di server WebDAV +) sia un progetto con cui penso di potermi divertire molto, sia in termini di realizzazione che di utilizzo.

Tuttavia, vedo la necessità di eseguire il mocking dei tipi qui per testare l'unità correttamente.

Ad esempio, mi affiderò a HttpListener per la porzione server Web del server WebDAV, e poiché questo tipo non ha un'interfaccia, ed è sigillato, non riesco a creare facilmente mock o stub.

A meno che non utilizzi qualcosa come TypeMock.

Quindi, se avessi usato TypeMock nei progetti di unit test su questa libreria, quanto sarebbe grave per i potenziali utenti?

I progetti sono realizzati in C # 3.5 per .NET 3.5 e 4.0 e i file di progetto sono stati creati con Visual Studio 2010 Professional.

Le attuali librerie di classi che avresti finito con il fare riferimento al tuo software non sarebbero ovviamente ingombranti di nulla di simile, solo le librerie di test unitari.

Cosa pensi di questo?

Ad esempio, ho nella mia vecchia base di codice, che è privata, la possibilità di avviare solo un server WebDAV con questo:

var server = new WebDAVServer();

Questo costruisce e possiede internamente un'istanza HttpListener e vorrei verificare tramite unit test che se dispongo di questo oggetto server, il listener interno viene eliminato. Se, d'altra parte, utilizzo il sovraccarico dove lo consegno come oggetto listener, questo oggetto non dovrebbe essere smaltito.

A corto di esporre l'oggetto listener interno al mondo esterno, qualcosa che non mi piace fare, come posso fare in modo che l'oggetto sia stato eliminato?

Con TypeMock posso deridere le parti di questo oggetto anche se non è accessibile tramite le interfacce.

L'alternativa sarebbe per me avvolgere tutto nelle classi wrapper, dove ho il controllo completo.

    
posta Lasse Vågsæther Karlsen 12.02.2011 - 19:31
fonte

3 risposte

3

Che ne pensi di utilizzare il pattern Adattatore , forse in combinazione con l'iniezione delle dipendenze?

Potresti fornire un'interfaccia / wrapper per HttpListener e scrivere il tuo codice su quella interfaccia. Puoi quindi prendere in giro l'interfaccia nei tuoi test con un framework di simulazione OSS o scrivere un'implementazione di simulazione manuale.

    
risposta data 12.02.2011 - 19:36
fonte
1

Per una cosa HTTP personalizzata ho finito usando C # Webserver invece di HttpListener. Questo progetto è fantastico e dovresti dargli un'occhiata.

E ovviamente c'è l'interfaccia IHttpListener .

    
risposta data 12.02.2011 - 19:49
fonte
0

Non è affatto un problema. In effetti, credo che le librerie e le guide Prism (fornite da MSFT) facciano esattamente questo con un diverso framework di test. Per compilare i progetti di test unitari ed eseguire i test, è necessario scaricare il framework di test separatamente e rilasciare un paio di DLL in alcune cartelle. Le istruzioni di installazione includono una spiegazione su come farlo.

    
risposta data 12.02.2011 - 21:37
fonte

Leggi altre domande sui tag