Pourquoi les attributs de test unitaire nécessitent-ils généralement des méthodes publiques?

J'ai récemment noté que l'ajout de [TestInitialize] à une méthode protégée dans un assembly .NET n'était pas respecté, mais si je rendais la méthode publique, elle était appelée par le testeur unitaire (Resharper dans ce cas). J'ai remarqué cela plusieurs fois dans le passé avec des méthodes de test.

Techniquement parlant, il est tout aussi facile de réfléchir à une méthode privée qu'à une méthode publique. En fait, la réflexion est une méthode utilisée pour tester unitairement des méthodes privées.

Alors, pourquoi dois-je rendre publiques toutes mes méthodes de test unitaire?

.net unit-testing

— Justin Dearing
source

Voilà une très bonne question. Le seul bon argument que j'ai entendu est qu'il suit le principe "programme vers une interface, pas vers une implémentation", une partie des principes SOLID.

— Robert Harvey

Je ne pense pas qu'il parle de tester ses classes, il parle des méthodes de test réelles qui sont appelées par le framework de test.

— jtiger

@RobertHarvey en Java, la raison d'une restriction similaire (par exemple dans JUnit) est que les concepteurs de framework ne veulent pas jouer avec setAccessiblece qui peut être bloqué par certains SecurityManager personnalisés

— gnat

vous devez tenir compte du fait que cette décision de conception a été prise pour un cadre général destiné à une large utilisation. Dans de tels cas, il est plus sûr pour le concepteur d'assumer et de se préparer au pire. S'il s'agissait, je ne sais pas, d'un cadre interne à l'entreprise (où l'on peut avoir la chance de garantir les politiques de sécurité souhaitées), ou s'il s'agissait d'un outil à finalité étroite et spécialisée (pensez "visionneuse pour les membres inaccessibles"), concepteur aurait d' autres options à considérer

— moucheron

@GregBurghardt Ce comportement se trouve dans Nunit, et probablement dans d'autres frameworks de test que Microsoft n'a pas écrits. Bien sûr, depuis que j'ai posé cette question, je comprends beaucoup plus sur .NET, mais je pense toujours que c'est une bonne question, et il y a une bonne discussion dans les commentaires.

— Justin Dearing

Réponses:

Vous devez tester ce que la classe ne , pas comment elle le fait.

En ce qui concerne le "monde extérieur", c'est tout ce que la classe rend publiquement disponible; votre framework de test fait la même hypothèse.

En testant quelque chose de "moins" que Public, vous plongez dans l'implémentation interne de la classe, qui est une mauvaise idée.

— Phill W.
source

Notez que la question concerne les méthodes de test et non les méthodes du système testé. S'il est vrai que OP soutient que vous pouvez utiliser la réflexion pour tester des choses "moins" que publiques, c'est un argument sur la capacité des frameworks de test à accéder à des méthodes privées. Le cadre de test doit utiliser la réflexion pour trouver les méthodes de test (qui sont marquées par un attribut), et doit donc utiliser la réflexion, dans cet esprit ... "pourquoi dois-je rendre toutes mes méthodes de test unitaire publiques?"

— Theraot

Les méthodes de test ont la possibilité d'accéder à des méthodes privées; avec Reflection, tout est possible. Je vois plus cette question sur l'opportunité [non] de le faire.

— Phill W.

En règle générale, il est préférable d'accéder uniquement aux méthodes publiques - lorsque vous créez une classe, vous créez également le contrat indiquant quelles autres classes doivent accéder à votre code. Donc, la réponse est très probablement juste parce que c'est une convention.

— Vetle
source

Cela ne répond pas vraiment à la question.

— RubberDuck