Question

J’ai BEAUCOUP de tests écrits pour un logiciel (ce qui est une très bonne chose), mais il a été construit essentiellement comme un test autonome en C #. Bien que cela fonctionne assez bien, il présente quelques inconvénients, notamment le fait qu’il n’utilise pas de cadre de test standard et finit par obliger la personne qui exécute le test à commenter les appels à des tests qui ne doivent pas être exécutés. (quand il n'est pas désiré d'exécuter la "suite" de test complète). J'aimerais l'intégrer à mon processus de test automatisé.

J'ai vu que l'édition test de VS 2008 avait la notion d'un "test générique" qui pourrait faire ce que je veux, mais nous ne sommes pas en mesure de dépenser de l'argent pour cette version. J'ai récemment commencé à utiliser la version Pro 2008 de VS 2008.

Ces méthodes de test suivent un schéma familier:

  • Faites quelques réglages pour le test.
  • Exécuter le test.
  • Réinitialiser pour le prochain test.

Chacune d'elles renvoie un booléen (réussite / échec) et une chaîne de référence à un motif d'échec, renseigné en cas d'échec.

Du côté positif, au moins les méthodes de test sont cohérentes.

Je suis assis ici ce soir et je réfléchis à l'approche que je pourrais prendre demain matin pour migrer tout ce code de test vers un cadre de test et, franchement, je ne suis pas très enthousiaste à l'idée de parcourir plus de 8 à 9 000 lignes de code de test à la main pour faire la conversion.

Avez-vous eu une expérience en entreprenant une telle conversion? Avez-vous des conseils? Je pense que je suis peut-être coincé à faire tout ce qui est en train de faire une recherche / un remplacement global et de changer les tests à la main.

Avez-vous des idées?

Était-ce utile?

La solution

Si vous utilisez NUnit (ce que vous devriez faire), vous devrez créer une nouvelle méthode de test pour chacune de vos méthodes de test actuelles. NUnit utilise la réflexion pour interroger la classe de test sur les méthodes marquées de l'attribut [Test] , ce qui explique comment il construit sa liste de tests affichés dans l'interface utilisateur. Les classes de test utilisent NUnit <. code> Assert pour indiquer s’ils ont réussi ou échoué.

Il me semble que si vos méthodes de test sont aussi cohérentes que vous le dites, toutes ces méthodes NUnit ressembleraient à ceci:

[Test]
public void MyTest()
{
   string msg;
   bool result = OldTestClass.MyTest(out msg);
   if (!result)
   {
      Console.WriteLine(msg);
   }
   Assert.AreEqual(result, true);

}

Une fois que cela fonctionne, votre prochaine étape consiste à écrire un programme qui utilise la réflexion pour obtenir tous les noms de méthode de test sur votre ancienne classe de test et génère un fichier .cs contenant une méthode NUnit pour chacun de vos fichiers d'origine. méthodes de test.

Ennuyeux, peut-être, mais pas extrêmement douloureux. Et vous n'aurez besoin que de le faire une fois.

Autres conseils

Vous êtes sur le point de vivre l'idiome de "Une once de prévention vaut mieux que guérir". C'est particulièrement vrai dans la programmation.

Vous ne faites aucune mention de NUnit (qui, je pense, a été acheté par Microsoft pour 2008, mais ne me retenez pas pour cela). Existe-t-il une raison particulière pour laquelle vous n’avez pas simplement utilisé NUnit?

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top