J'écris des tests de la Nunit pour les opérations de base de données. Évidemment, si y a-t-il un moyen de spécifier Une «commande» pour les tests à exécuter, dans celle-ci si le premier test échoue, les tests suivants sont ignorés? Dans la même ligne, est-il un moyen de commander les classes de test de l'unité elles-mêmes? Par exemple, je voudrais d'abord exécuter mes tests pour les opérations de base de données de base avant les tests des données de déclenchement rond de l'interface utilisateur. Note: Ceci est un peu différent d'avoir Les tests dépendent l'un de l'autre, cela ressemble plus à ce que quelque chose fonctionne d'abord avant d'exécuter un tas de tests. C'est une perte de temps pour, par exemple, exécuter un tas d'opérations de base de données si vous ne pouvez pas obtenir une connexion à la base de données en premier lieu. EDIT: Il semble que certaines personnes manquent le point. Je ne fais pas cela: plutôt, je fais cela: en d'autres termes, je Voulez-vous vous assurer que les données peuvent être ajoutées en premier lieu avant que je puisse vérifier si elle peut être récupérée. Les gens supposent que j'utilise des données du premier test pour réussir le deuxième test lorsque cela n'est pas le cas. J'essaie de m'assurer qu'une opération est Comme je l'ai déjà dit, vous devez vous assurer de pouvoir obtenir une connexion à la base de données. avant d'exécuter des opérations de base de données. Ou que vous pouvez ouvrir un fichier avant d'effectuer des opérations de fichier. Ou connectez-vous à un serveur avant de tester les appels d'API. Ou ... vous obtenez le point. ajoutez () échoue, alors get () échouera également. Cependant, il semble déconcerter lorsque ajoutez () et get () échoue car il semble qu'il y a deux problèmes au lieu d'une seule.
7 Réponses :
Créer une variable globale et retour dans le test pour Obtenez code> sauf si Ajouter code> Définissez-le sur TRUE (faites-le dans la dernière ligne de Ajouter Code> ): public boolean addFailed = false;
public void testAdd () {
try {
... old test code ...
} catch (Throwable t) { // Catch all errors
addFailed = true;
throw t; // Don't forget to rethrow
}
}
public void testGet () {
if (addFailed) return;
... old test code ...
}
Merci. Ce n'est pas très élégant, mais on dirait que Nunit ne supporte pas cette fonctionnalité de manière native.
Ce que vous voulez, c'est un piratage, alors la solution en est un aussi;)
Je ne suis pas un fan de cette solution. La méthode des testsGet n'a pas été adoptée, elle n'a pas fonctionné. Il devrait être rapporté comme tel.
@MLK: C'est un hack. Néanmoins, il ne sert à rien d'exécuter un test lorsque vous savez déjà que cela échouera et enterrer la cause unique de l'échec sous un tas d'erreurs héritées.
@MLK: Ce serait bien si les cadres de test avaient un moyen de dire «le test a été ignoré car cela échouerait de toute façon». Python fait-il de cette façon (pour Mac / Windows teste lorsque vous exécutez la suite sur Linux, par exemple).
Cette solution se rapproche dangereusement de faux car cela dépend de l'ordre de la course; Actuellement, Nunit fonctionne selon le nom de test, tout irait bien. Mais si dans le futur Nunit modifie la séquence d'exécution, que testget est exécuté avant avant testtadd ? Dans ce cas, TestaDDD sera exécuté, mais testget ne sera pas!
@Aaron - ça fait. Supposons, voyez ma réponse ci-dessous.
Je ne pense pas que ce soit possible en dehors de la boîte.
Quoi qu'il en soit, votre conception de classe de test comme vous l'avez décrite rendra le code de test très fragile.
Je ne cours pas le test Ajouter () Pour ajouter des données dans la base de données, puis en exécutant le test get () Test pour obtenir les données. Plutôt, je veux m'assurer que ajouter () fonctionne d'abord avant le get () test, un peu comme dites "OK, puis-je ajouter des données dans la base de données? Bien, maintenant Ajoutez ces données de test et voyez si je peux le récupérer. "
MBUnit semble avoir un DEPENDONSONATRIBUT qui vous permettrait de faire ce que vous voulez.
si l'autre appareil de test ou test la méthode échoue alors ce test ne sera pas Cours. De plus, les forces de dépendance ce test à courir après celles-ci dépend de.
Je ne sais rien de Nunit cependant.
Merci, c'est à peu près exactement ce que je cherchais. Il est encore assez tôt que je puisse passer à Mbunit si je veux, alors je vais y regarder.
Nunit prend en charge un " donc dans le contexte: supposum.that " Syntaxe pour valider la configuration.C'est documenté dans le cadre du théorie (merci Clairestreb ). Dans le nunit.framework Espace de noms est une classe supposons . Pour citer la documentation:
Cela devrait être la réponse acceptée, une excellente façon de déclarer les dépendances, et «non concluante», c'est précisément le bon résultat, qui, dans la plupart des cadres de test, finissent par orange: ce qui doit encore être fait.
7 ans plus tard, mais je reviens à ce poste, voici le doc: Nunit. org / index.php? p = Théory & r = 2.5
Les tests doivent get () , mettez-le là dans l'étape de configuration.
Sauf que ce n'est pas fragile. Vous manquez le point. Vous devez vous assurer que certaines choses sont disponibles avant de pouvoir tester. Dans mon cas, je dois m'assurer que ajoutez () fonctionne car sans cela, get () n'aura aucune donnée à obtenir. Peu importe si c'est dans la configuration ou non parce que j'utilise ajouter () dans mon get () test, mais je dois m'assurer que Ajouter () fonctionne réellement avant d'exécuter le test.
C'est ce que fait la moqueur et l'encombrement. Dans le test de get () , vous devez être capable de fournir des données factices pour obtenir () à utiliser afin que le test puisse être exécuté sans ajouter () . Cela pourrait vouloir dire passer dans une sous-classe de ajouter () qui ne fait rien qui puisse le faire échouer. Le point est qu'un test unitaire ne doit tester que l'unité en question. Il devrait être un moyen de tester get () sans tester ajouter (). Si vous obtenez le correctif que vous demandez, vous ne pouvez pas savoir si get () fonctionne ou non si ajoutez () est cassé. Cela signifie que vous ne pouvez pas obtenir un instantané fiable de votre système.
@Daniel T. Il vous manque le point. Les tests doivent toujours être indépendants les uns des autres. Cela signifie utiliser ajouter () dans un test pour get () n'est pas une bonne idée. Si ajoutez () casse, les tests de obtiennent () va casser aussi. Votre test n'est pas isolé. Qui a dit que vous devez utiliser ajouter () pour préparer votre dB pour obtenir () ...
@EricsChaefer: Comment autrienez-vous des données dans la base de données? Bien sûr, vous pouvez tous les moquer et faire du talon, mais à ce stade, vous ne testez plus la base de données. Ce que je demande, c'est exactement quelque chose à résoudre la situation que vous avez décrite: un moyen de ne pas exécuter get () si ajoutez () échoue.
@EricsChaefer: Cela (les tests doivent être indépendants) est vrai lorsque vous parlez de tests d'unités. Nunit peut également être utilisé pour des tests de niveau supérieur et ceux-ci peuvent être dépendants. De plus, vous pouvez très bien décider de ne pas exécuter des tests complexes lorsque la fonctionnalité de base échoue, en particulier dans le développement de l'essai.
Je pense que le problème est que vous utilisez Nunit pour exécuter autre chose que le type de tests d'unité que Nunit a été effectué pour exécuter.
Essentiellement, vous voulez que Addtest fonctionne avant GetTest et que vous souhaitez que Nunit arrête d'exécuter des tests si AddTest échoue.
Le problème est que c'est que c'est antithétique aux tests d'unités - les tests sont supposés être complètement indépendants et exécutés dans n'importe quel ordre.
Le concept standard de test unitaire est que si vous avez un test autour de la fonctionnalité "Ajouter", vous pouvez utiliser la fonctionnalité "Ajouter" dans le test "Obtenir" et ne vous inquiétez pas si "Ajouter" fonctionne dans le ' Obtenez le test. Vous savez "Ajouter" Travaux - vous avez un test pour cela.
Le «premier» principe ( http://agileinaflash.blogspot.com/2009 /02/first.html ) décrit comment les tests unitaires doivent se comporter. Le test que vous souhaitez écrire viole les deux 'i' (isolé) et 'R' (reproductible).
Si vous êtes préoccupé par la connexion de la base de données qui tombe entre vos deux tests, je vous recommanderais que vous recommandez plutôt que de vous connecter à une base de données réelle pendant le test, votre code doit utiliser une sorte d'interface de données et pour le test, vous. devrait utiliser une interface simulée. Si le point du test est pour exercer la connexion de base de données, vous pouvez simplement utiliser le mauvais outil pour le travail - ce n'est pas vraiment un test d'unité.
Ce que vous avez dit a beaucoup de sens, mais j'ai toujours du mal à comprendre comment je peux isoler obtenir () à partir de ajouter () . La façon dont je le vois, c'est comme avoir une boîte vide. Vous devez être capable de mettre quelque chose à l'intérieur de la boîte avant de pouvoir tester si vous pouvez le sortir.
Ils sont aussi isolés que possible. Si vous voulez 'obtenir ()', vous devez évidemment «mettre ()» d'abord dans ce même test (ou dans la configuration). L'isolement vient du fait que vos deux tests testaient des choses totalement différentes - vos premiers tests «Mettez ()» et vos deuxième essai 'Get ()'. Si "Met ()" échoue, ils échoueront tous les deux - mais ça va. Il n'y a pas de règle de test de l'unité qui dit si une zone du système se casse, il devrait casser exactement un test - il doit simplement briser au moins un test, espérons-le, espérons-le, dont l'une seule teste spécifiquement cette zone.
J'avais une conversation avec un collègue et il a dit que, même si même en théorie, ce serait bien d'empêcher la cascade échoue, il y a rarement une affaire dans la pratique où une cascade échoue en fait quelque chose. En d'autres termes, si vous avez plus de 200 tests et le test pour voir si les données peuvent être récupérées à partir de la base de données ont échoué, il serait bien d'ignorer le reste des tests car ils vont automatiquement échouer également. Mais comme les tests fonctionnent généralement rapidement et doivent être regroupés en fonction de la couche que vous testez, il devrait être assez facile de voir tracer le problème.
Vous ne pouvez assumer aucune commande d'exécution de l'appareil de test, de sorte que les conditions préalables doivent être vérifiées dans vos cours de test.
séparer votre test d'additionner en une classe d'essai par exemple. AddTestSTs, et mettez le (s) test (s) Obtenir (S) dans une autre classe de test, par ex. classe getestest.
dans la méthode [TestFixTreSetup] de la classe GetTestSTS, vérifiez que vous avez un accès à la base de données de travail (par exemple, que l'Ajout du travail), et sinon, affirmez.igne ou peu concluante, comme vous le souhaitez.
Ceci abandonnera l'appareil de test GetTestS lorsque ses prérequis ne sont pas remplis et ignoreront d'essayer d'exécuter l'un des tests de l'unité qu'il contient. (Je pense! Je suis une Nunit Newbie.)
La réponse acceptée est faux ! Voir les commentaires