novembre
2009
Un article de nico-pyright(c)
Sans rentrer dans le débat de « Pourquoi vouloir tester une méthode privée », il est possible de tester unitairement des méthodes privées.
Si c’est possible, je recommande d’utiliser plutôt le qualificateur
plutôt que
Dans ce cas, il devient possible d’utiliser l’attribut InternalsVisibleTo afin d’indiquer que le projet de test pourra accéder aux classes/méthodes internes.
Cela se fait en renseignant cet attribut dans le fichier AssemblyInfo.cs du projet contenant la classe interne. On lui indique l’assembly qui sera autorisée à utiliser les éléments internes de la classe.
Par exemple :
1: [assembly: System.Runtime.CompilerServices.InternalsVisibleTo("MonAssembly, PublicKey=laclepubliquesibesoin")]
Notez que si l’assembly est signée, il faudra renseigner la clé publique complète, que l’on peut trouver grâce à la commande :
On pourra également utiliser l’assistant de Visual Studio, grâce au menu contextuel qui s’affiche lors du clic sur le bouton droit :
Il suffira de choisir la méthode interne à tester :
Une autre solution est de, toujours avec l’assistant, demander à Visual Studio de générer un accesseur privé afin de pouvoir tester les méthodes privées.
Grâce au menu contextuel, on peut :
Il génère dans le projet de test l’accesseur privé :
et on pourra utiliser un code du genre pour tester sa méthode privée :
1: MonWebService_Accessor test = new MonWebService_Accessor();
2: int value = test.UneMethodePrivate();
3: Assert.AreEqual(10, value);
Voilà pour le test de méthode privée.
4 Commentaires + Ajouter un commentaire
Commentaires récents
- dans [Tests] Arrange Act Assert, une traduction ?
- dans [UnitTest][C#] Tester une méthode privée
- dans Récupérer une valeur d’un contrôle depuis une autre Form / inclusions croisées et déclaration anticipée
- dans Tutoriel : Utiliser la ListBox et l’Isolated Storage dans vos applications Windows Phone 7 avec Silverlight
- dans Tutoriel : Utiliser la ListBox et l’Isolated Storage dans vos applications Windows Phone 7 avec Silverlight
Archives
- janvier 2013
- avril 2012
- janvier 2012
- juin 2011
- janvier 2011
- décembre 2010
- novembre 2010
- septembre 2010
- juin 2010
- mars 2010
- février 2010
- janvier 2010
- décembre 2009
- novembre 2009
- octobre 2009
- septembre 2009
- août 2009
- juillet 2009
- mai 2009
- avril 2009
- mars 2009
- janvier 2009
- décembre 2008
- novembre 2008
- octobre 2008
- septembre 2008
- août 2008
- juillet 2008
- juin 2008
- mai 2008
- avril 2008
- mars 2008
- février 2008
- janvier 2008
- décembre 2007
- novembre 2007
- octobre 2007
- septembre 2007
- août 2007
- juillet 2007
- juin 2007
- mai 2007
Je suis pas du tout d’accord, pour moi il est indispensable de tester unitairement toutes les méthodes du programme, y compris les méthodes privées ^^
Les tests unitaires sont la justement pour permettre de vérifier que quelles que soient les modifications faites à une partie du code, le reste continuera parfaitement de fonctionner. Si tu changes une méthode qui appelle une méthode privée et pour laquelle tu n’as pas forcément prévu les nouveaux paramètres avec lesquels elle appelle, ton programme plantera
En gros les tests unitaires servent à ce que le code soit le plus robuste et le plsu simple à débuger possible
Ex: tu as une mèthode publique qui appelle une méthode privée B qui elle même appelle une méthode privée C. Si y’a un soucis dans C et que tu t’en rends compte avec un test dans A tu vas passer beaucoup plus de temps à d’ebugger que si tu vois que tes tests plantent directement dans C.
Le plus simple est d’utiliser Visual T#: un langage de programmation de tests unitaires, compatible C#.
Il possède l’opérateur .- qui permet d’accéder à des déclarations privées SANS CHANGER LE CODE TESTÉ!
Pour plus d’informations: http://fr.www.prettyobjects.com/tsharp.aspx?sid=overview
C’est présent dans la version pro, mais effectivement, je ne saurai te dire si c’est présent dans les versions inférieures.
Je suis d’accord avec toi, normalement on ne devrait pas avoir à tester des méthodes privées. Je considère qu’exceptionnelement, il peut être utile d’avoir à tester des méthodes internes notamment si elles sont partagées par plusieurs classes de l’assembly.
Mon grain de sel…
En test unitaire, il ne devrait pas être nécessaire de tester une méthode privée, vu que ces tests doivent avoir lieu du point de vue d’un client (mais bon, comme tu rentre pas dans le débat, moi non plus
)
Pour la partie InternalsVisibleTo, pour rajouter une couche, ce n’est pas le token de la public key, mais la public key complete, genre : 0024000004800000940000000602000000240000525341310004000001000100cfb8bc23b86a08e70d021dd53d3b0293e716e71015870bdcc58a0231a4228618851a83e06077f5a44f42beb2baf356ad2d344521a96b0081ed0f25f9227523e3625eda524efe1cf2e1e5e41f3693a76ec52347684b8129a4bb2d5fc49681adf33da0eecc4f81f011af4539d12ae1b4e760b5ce32d766db1012d44028381f0b4
Sinon, tu peux aussi accéder aux membres privés par reflexion, ce qui doit être grosso modo ce que fait l’assistant, encore faut-il avoir l’assistant en question, qui n’est, si je me rappelle bien, pas fourni dans la version pro