2010-03-24 10 views
6

Ho appena finito il libro di Michael Feathers Working Effectively with Legacy Code. È stato un ottimo libro su come creare efficacemente cuciture di prova e sfruttarle per ottenere il codice esistente sotto test.Cuciture di collegamento in .NET

Una delle tecniche di cui parlava era l'uso di "cuciture di collegamento". Fondamentalmente l'idea era che se avessi un codice che dipendesse da un'altra libreria potresti usare il linker per inserire una libreria diversa per i test piuttosto che per la produzione. Ciò consentirebbe di percepire condizioni di test attraverso una libreria fittizia, o evitare di chiamare in librerie con effetti reali (database, e-mail, ecc.)

L'esempio che ha fornito era in C++. Sono curioso di sapere se questa tecnica (o qualcosa di simile) è possibile in .NET/C#?

+1

Si noti che questa dovrebbe essere l'ultima risorsa quando tutto il resto fallisce. Se è abusato, dopo un certo punto si può perdere traccia di quale libreria si sta utilizzando dove, e questo può portare a bug sottili sia nei test che nella produzione. –

+0

Oh sono assolutamente d'accordo. E TBH non sono sicuro che lo userei mai. Sono più curioso di sapere se è addirittura possibile sullo stack .NET. – RationalGeek

risposta

4

sì è possibile in .Net. Nel caso più semplice, si può sostituire un assieme con un altro con lo stesso nome

Con un assembly con un nome forte, è necessario modificare il numero di versione e quindi configurare i binding di assembly per sovrascrivere la versione "collegata" del tempo di compilazione. livello azienda, macchina, utente o directory

Ci sono alcuni avvertimenti relativi alla sicurezza. Se l'assembly che si desidera sostituire è stato fortemente denominato, sarà necessario ricreare la stessa chiave pubblica nella firma dell'assembly.

In altre parole, se lo sviluppatore dell'applicazione non desidera che le librerie vengano "derise" (o magari sostituite con codice dannoso), è necessario assicurarsi che l'assembly sia firmato e che la chiave privata non sia disponibile pubblicamente.

Questo è il motivo per cui non è possibile prendere in giro DateTime perché Microsoft ha fortemente chiamato le librerie di base di .Net.

Problemi correlati