Unité de tester des méthodes privées en c#

Question

Visual Studio permet à l'unité de l'essai de méthodes privées via généré automatiquement accesseur de la classe. J'ai écrit un essai d'une méthode privée qui compile correctement, mais il ne parvient pas à l'exécution. Un assez minime version du code et le test est:

//in project MyProj
class TypeA
{
    private List<TypeB> myList = new List<TypeB>();

    private class TypeB
    {
        public TypeB()
        {
        }
    }

    public TypeA()
    {
    }

    private void MyFunc()
    {
        //processing of myList that changes state of instance
    }
}    

//in project TestMyProj           
public void MyFuncTest()
{
    TypeA_Accessor target = new TypeA_Accessor();
    //following line is the one that throws exception
    target.myList.Add(new TypeA_Accessor.TypeB());
    target.MyFunc();

    //check changed state of target
}

L'erreur d'exécution est:

Object of type System.Collections.Generic.List`1[MyProj.TypeA.TypeA_Accessor+TypeB]' cannot be converted to type 'System.Collections.Generic.List`1[MyProj.TypeA.TypeA+TypeB]'.

Selon intellisense - et donc je suppose que le compilateur cible est de type TypeA_Accessor. Mais à l'exécution, il est de type TypeA, et donc la liste ajouter échoue.

Est-il possible que je puisse arrêter cette erreur? Ou, peut-être plus probable, que d'autres conseils d'autres personnes (je prévois peut-être "n'est pas tester les méthodes privées" et "n'ont pas les tests unitaires de manipuler l'état des objets").

Answer 1

Vous pouvez utiliser ce...

Answer 2

Oui, ne pas Tester les méthodes privées.... L'idée d'une unité de test est de tester l'appareil par son public "API".

Si vous trouvez vous avez besoin de tester un grand nombre de comportements privés, vous avez probablement une nouvelle "classe" qui se cache dans la classe que vous essayez de tester, de l'extraire et de le tester par son interface publique.

Un morceau de conseils / outil de Réflexion..... Il y a une idée qu'aucune méthode ne devrait être privé. Ce qui signifie que toutes les méthodes devraient vivre sur une interface publique d'un objet.... si vous sentez que vous avez besoin pour le rendre privé, il est probable qu'il vit sur un autre objet.

Ce morceau de conseils n'est pas tout à fait dans la pratique, mais surtout de bons conseils, et souvent il va pousser les gens à se décomposer leurs objets en objets de petite taille.

Answer 3

"Il n'y a rien qui s'appelle comme standard ou des meilleures pratiques, probablement, ils sont juste de l'opinion publique".

En va de même pour cette discussion.

Tout dépend de ce que vous pensez est une unité , si vous pensez que l'UNITÉ est une classe puis vous ne serez frappé de la méthode publique. Si vous pensez que l'UNITÉ est lignes de code de frapper les méthodes privées ne sera pas vous faire sentir coupable.

Si vous voulez vous prévaloir privé méthodes que vous pouvez utiliser "PrivateObject" de la classe et de l'appel de la méthode invoke. Vous pouvez regarder cette approfondi de la vidéo sur youtube ( http://www.youtube.com/watch?v=Vq6Gcs9LrPQ ) qui montre l'utilisation de la PrivateObject" et examine également si le test de méthodes privées sont logiques ou pas.

Answer 4

Une autre pensée ici est d’étendre les tests aux classes/méthodes de « internes », donnant un sens de boîte blanche de ce test. Vous pouvez utiliser InternalsVisibleToAttribute sur l’Assemblée pour exposer ces pour séparer les modules de test unit.

Answer 5

Vous pouvez créer une classe wrapper autour de la classe qui contient la méthode privée que vous souhaitez tester. Cette classe wrapper contient une méthode appelée Call_MyPrivateFunction, et qui appelle à son tour la fonction privée de sa classe de base.

Veuillez noter que le niveau d’accès du changement schould méthode [protégée]

Exemple de code :

Le code de test unitaire pourrait ressembler :