Drapeau spécial du compilateur pour les tests unitaires

Question

J'ai une question concernant la suite de tests intégrée à Visual Studios. Est-ce que VS studio exécute ces tests avec des drapeaux de compilation spéciaux appliqués ?

La description du problème est la suivante. J'ai surchargé la fonction Equals sur l'une de mes classes. Lors des tests, il serait intéressant qu'elle puisse me donner des informations supplémentaires sur les membres de la classe qui ne sont pas du tout égaux.

C'est pourquoi j'aimerais que certains messages ne soient envoyés que si l'application fonctionne en mode test.

Merci de votre réponse ! Andreas

Answer 1

VS compile/construit les projets avec la configuration de construction actuellement sélectionnée. Une solution pourrait donc consister à créer soi-même une configuration de compilation distincte, puis à utiliser une constante (par exemple TEST) pour les projets de cette configuration de compilation particulière. L'exécution de la méthode de sortie peut alors être restreinte à l'aide de l'option #if TEST ou avec la directive [Conditional("TEST")] attribut. Vous pourriez configurer votre serveur de compilation pour qu'il exécute toujours les tests avec cette configuration de compilation particulière, ce qui vous permettrait d'obtenir des résultats supplémentaires. Vous devrez cependant passer manuellement d'une configuration à l'autre lors de l'exécution des tests à partir de VS

Answer 2

Créez une nouvelle configuration de solution "Test" (si vous ne l'avez pas encore) et passez-y. Ouvrez les paramètres du projet, passez à l'onglet Build et définissez un nouveau symbole TEST. Appuyez sur OK.

Modifiez votre mise en œuvre de la règle des égalités en

public override bool Equals (object obj)
{
    #if TEST
     // Your implementation
    #else
      return base.Equals (obj);
    #endif
}

Cela compilera un corps de méthode différent pour votre configuration de test.

Answer 3

Je dois dire que je n'aime pas l'idée de mettre de la compilation conditionnelle partout dans votre code. Cela rend plus difficile la lecture et le débogage de votre code.

Peut-être devriez-vous prendre un peu de recul et réaliser que vous avez deux ensembles différents d'algorithmes pour déterminer si un objet est égal. Vous pourriez extraire ce code de la méthode Equals en utilisant une méthode Modèle de conception stratégique .

Ensuite, au moment de l'exécution, vous pouvez sélectionner la stratégie pour la méthode Equals par le biais de l'injection de dépendance ou peut-être une simple fonction comme celle-ci dans votre classe de base :

public override bool Equals (object obj)
{
    if ( EqualsStrategy != null)
    {
        return EqualsStrategy.Equals(this,object);
    }
    else
    {
       return base.Equals(obj);
    }
}

Dans vos tests unitaires, vous devez initialiser EqualsStrategy avec la fonction que vous souhaitez utiliser.

Answer 4

Je vous déconseille vivement d'insérer des test uniquement dans votre application. L'objectif d'un test (unitaire) est de tester la qualité de production du logiciel, et non d'exercer un code de test uniquement.

Si votre code testé uniquement fonctionne, mais que la version de production est cassée, votre test n'a aucune valeur.

Au lieu de cela, vous devriez écrire votre test de telle sorte qu'une seule chose puede se tromper. Ainsi, si le test échoue, vous savez déjà ce qui ne va pas. Ainsi, si vous testez une méthode Equals qui prend en compte deux propriétés, écrivez un ensemble de petits tests qui vérifient ce qui se passe dans toutes les combinaisons possibles des deux propriétés et vérifiez le résultat de la méthode Equals.

Après cela, vous pouvez être sûr que la méthode Equals est correctement implémentée et que vous n'avez pas besoin de la tester ailleurs.

Une autre solution pourrait être d'ajouter une aide au test qui effectue une journalisation supplémentaire. J'aime utiliser des méthodes d'extension pour cela. Par exemple :

public static class TestExtensions
{
  public static void ShouldEqual( this YourType subject, YourType other )
  {
     // Check parameters for null here if needed
     if( !subject.Equals( other ) )
     {
       // custom logging here
       Assert.Fail("Objects are not equal"); // test fails
     }
  }
}