J'utilise Nunit pour écrire des tests d'unité pour une génération de milles de Libary. Sa bibliothèque contient beaucoup de débogage.Arasseurs qui déclenchent une entrée non valide. Lorsque j'écris les tests de l'unité et donnez une entrée invalide à sa bibliothèque, son débogage.Assert jette une boîte de message se plaignant de la mauvaise entrée.
Je pense que c'est une bonne chose que sa bibliothèque jette une affirmation sur une entrée non valide, mais je souhaite en même temps que les tests de l'unité couvrent une mauvaise entrée. Mais lorsque je fais cela, la boîte de message apparaît et je dois cliquer sur OK pour continuer avec les tests d'unité restants.
Si ce n'est pas clair, mon problème est que le processus de test de l'unité s'arrête sur le débogage.Assert. Les gens sont censés exécuter leurs tests unitaires avant tout checkin et il est censé être automatique et ne doit pas vomir des messages à moins qu'un test a échoué.
Quelle est la "meilleure" approche dans ce cas?
3 Réponses :
Jetez un coup d'œil à la documentation MSDN pour le méthode debug.assert . Spécifiquement sous "remarques", il explique comment vous pouvez désactiver l'interface utilisateur: Je suggère donc que le fichier de configuration de la candidature a ceci par défaut et que votre collègue s'allume sur l'interface utilisateur chaque fois qu'il le ressent utile de le faire.
Comme Henk déjà noté, supprimer l'interface utilisateur est inutile, car vous voulez que votre code échoue. Lorsque vous ne voulez pas modifier votre code, vous pouvez écrire un auditeur de trace personnalisé qui jette une exception, comme suit: et vous pouvez l'enregistrer comme suit: p> XXX PRE> Comme vous pouvez déjà vous attendre à ce que le nom Mon conseil est de modifier le code et d'utiliser la normale ProductionTracelistener Code>, j'utilise cette chose dans mon environnement de production (applications Web), et non dans mes tests d'unité. Bien que vous puissiez utiliser ce truc dans vos tests de l'unité, je vous conseille de changer votre code. OMI, vous ne devriez utiliser que des affirmations pour les chemins de code qui ne doivent jamais courir, et s'ils le font, le test devrait échouer. Dans votre situation, vous voulez avoir un test suivant lorsqu'un affirmation échoue, qui est contre-intuitif. P> si (x) jette argumentexception () code > Vérifie des conditions préalables (ou utilisez CongedEdge.Conditions ) et utilisez ces affirmations uniquement pour les chemins de code qui ne doivent jamais courir. Essayez également d'utiliser trace.assert code> au lieu de debug.assert code>, car vous souhaitez également que ces affirmations soient vérifiées dans votre environnement de production. Lorsque vous avez fait que vous pouvez utiliser le ProductionTracelistener Code> dans votre environnement de production, et ce UnitestTracelisener code> dans vos tests d'unité. P> public class UnitTestTraceListener : DefaultTraceListener
{
public override void Fail(string message, string detailMessage)
{
string failMessage = message;
if (detailMessage != null)
{
failMessage += " " + detailMessage;
}
// Call to Assert method of used unit testing framework.
Microsoft.VisualStudio.TestTools.UnitTesting.Assert.Fail(
failMessage);
}
}
Cela aurait fière allure pour Trace.Assert (), mais l'OP mentionne debug.Assert ().
De plus, vous voulez que le code échoue dans les tests de l'unité Lorsque vous les exécutez dans le cadre d'une station de construction automatisée. Les affirmations sont destinées aux développeurs bénéficient tout en exécutant le code.
@HENK && @ROB: Je ne suis pas sûr de vous suivre. Configuration du ProductionTracelistener Dans l'environnement de test de l'unité permettrait aux tests de l'unité d'échec lorsque les méthodes n'ont pas lancé la assertiontionException attendue . Lorsque des tests d'unités sont courus dans le mode de débogage, cela fera exactement comme il gêne, n'est-ce pas? S'il vous plaît éclairer moi.
Steven, Debug.Assert () est mauvais, car il rend la construction de débogage se comporter différent de la construction de la libération. Quel comportement voulez-vous tester?
Henk, c'est exactement pourquoi je conseille d'utiliser trace.assert . Avoir une construction de débogage se comporter différemment est une mauvaise chose. Je pense que nous pensons la même chose à ce sujet.
Une option simple que je trouve efficace consiste à utiliser la norme consoleTraCelistener , qui permettra aux chèques debug.Assert de tirer parti, mais dirigera leur sortie à l'onglet de sortie de texte Nunit sans influencer autrement le test de l'unité.
Vous pouvez ajouter Ceci à votre configuration de test ... n'oubliez pas de vérifier la sortie de texte lorsqu'un test échoue!