2010-03-24 3 views
6

J'ai récemment terminé le livre de Michael Feathers Working Effectively with Legacy Code. C'était un excellent livre sur la façon de créer efficacement des coutures de test et de les exploiter pour tester le code existant.Liaisons de liens dans .NET

L'une des techniques dont il a parlé consistait à utiliser des "coutures de liaison". Fondamentalement, l'idée était que si vous aviez du code qui dépendait d'une autre bibliothèque, vous pourriez utiliser l'éditeur de liens pour insérer une bibliothèque différente pour les tests que pour la production. Cela vous permettrait de détecter les conditions de test grâce à une bibliothèque fictive, ou d'éviter d'appeler des bibliothèques qui ont des effets réels (bases de données, courriels, etc.).

L'exemple qu'il a donné était en C++. Je suis curieux de savoir si cette technique (ou quelque chose de similaire) est possible dans .NET/C#?

+1

Notez que cela devrait être un dernier recours quand tout le reste échoue. Si elle est surutilisée, après un certain point, vous risquez de perdre la trace de la bibliothèque que vous utilisez, ce qui peut conduire à des bugs subtils à la fois dans les tests et en production. –

+0

Oh, je suis absolument d'accord. Et TBH je ne suis pas sûr que je l'utiliserais jamais. Je suis plus curieux de savoir si c'est possible sur la pile .NET. – RationalGeek

Répondre

4

Oui, il est possible en .Net. Dans le cas le plus simple, vous

Avec un assembly fortement nommé, vous devez modifier le numéro de version, puis configurer les liaisons d'assembly pour remplacer la version "liée" de la compilation. Cela peut être fait sur un serveur. niveau entreprise, machine, utilisateur ou répertoire

Il y a quelques mises en garde, liées à la sécurité. Si l'assembly que vous souhaitez remplacer a été fortement nommé, vous devrez recréer la même clé publique en signant l'assembly. En d'autres termes, si vous, en tant que développeur d'applications, ne voulez pas que vos bibliothèques soient "raillées" (ou remplacées par du code malveillant), vous devez vous assurer que l'assembly est signé et que la clé privée n'est pas disponible publiquement. C'est pourquoi vous ne pouvez pas vous moquez de DateTime - parce que Microsoft a fortement nommé les bibliothèques de base de .Net.