Lorsque vous utilisez Assert (...) Si un test logique échoue, le test de l'unité est abandonné et le reste du test de l'unité n'est pas exécuté. Existe-t-il un moyen de faire échouer le test logique, mais simplement de fournir un avertissement ou quelque chose et exécutez toujours le reste du test de l'unité?
Un exemple du contexte est que j'ai un test qui crée des étudiants, des enseignants et des classes, crée des relations, les place dans une base de données. Ensuite, certains packages SSIS sont exécutés sur cette base de données qui prend les données existantes et la convertit en un autre schéma de base de données dans une autre base de données. Le test doit alors vérifier la nouvelle base de données pour certaines choses comme le bon nombre de lignes, actions, etc.
Évidemment, d'autres tests sont des suppresses et des mods, mais tous suivent la même structure - Créez des données dans la source DB, exécutez des packages SSIS, vérifiez les données dans la cible DB.
7 Réponses :
On dirait que vous essayez de tester trop de choses dans un seul test.
Si une condition préalable n'est pas remplie, alors le reste du test ne passera pas non plus. Je préférerais mettre fin au test dès que je sais que les choses ne sont pas ce que j'attends.
Les concepts de tests d'unités sont l'échec rouge, passe verte. Je sais que Mstest permet également un jaune, mais cela ne va pas faire ce que vous voulez. Vous pouvez faire une assertion.ConConclusive pour obtenir un feu jaune. J'ai utilisé cela lorsque j'ai travaillé sur une base de code qui comptait de nombreux tests d'intégration figurant sur des données de base de données spécifiques. Plutôt que d'avoir l'échec du test, j'ai commencé à avoir les résultats ne sera pas concluant. Le code pourrait avoir travaillé juste bien, mais les données manquaient. Et il n'y avait aucune raison de croire que les données seraient toujours là (elles n'étaient pas bonnes tests IMO).
Le test de l'unité est noir et blanc - que vous passez des tests ou non, vous cassez la logique ou non, que vos données dans DB sont correctes ou non (bien que les tests d'unités avec DB ne soient plus des tests unitaires en soi).
Qu'est-ce que vous allez faire avec l'avertissement? Est-ce que cela passe ou échoue? Si c'est passer, alors quel est le point de tester l'unité dans ce cas? Si c'est échouer .. bien .. juste échouer alors.
Je suggère de dépenser un peu de temps à déterminer ce qui devrait être testé unitaire et comment il devrait être testé unitaire. "Test de l'unité" est un terme cliché utilisé par beaucoup pour des choses très très différentes.
Le point est que vos tests pourraient être exécutés dans le cadre d'un pipeline CI / CD, et que dans ce cas, le test peut parfois échouer, mais vous ne voulez pas qu'il ne cassait pas la construction et le déploiement.
De ce que vous avez expliqué dans la question, il s'agit davantage d'un test d'acceptation (qu'un test d'unité). Les cadres de test unitaire sont conçus pour échouer rapidement. C'est pourquoi l'affirmation se comporte comme ça (et c'est une bonne chose.)
Revenir à votre problème: Vous devez jeter un coup d'œil à l'aide d'un cadre de test d'acceptation telle que Fitnesse, ce qui favoriserait ce que vous voulez, montrez-moi les étapes qui ont échoué mais continuent d'exécuter jusqu'à la fin.
Toutefois, si vous devez utiliser un cadre de test unitaire, utilisez une variable / paramètre de collecte pour simuler ce comportement. par exemple.
dans le test
- Ajoutez un message d'erreur descriptif pour chaque étape d'échec
- à la fin du test, affirmez que la variable de collecte est vide
Si vous utilisez gallio / mbunit strong> , vous pouvez utiliser assert.multiple code> pour réaliser ce que vous voulez. Il capture les assertions défaillantes mais n'arrête pas immédiatement l'exécution du test. Toutes les affirmations défaillantes sont collectées et rapportées plus tard à la fin du test.
[Test]
public void MultipleAssertSample()
{
Assert.Multiple(() =>
{
Assert.Fail("Boum!");
Assert.Fail("Paf!");
Assert.Fail("Crash!");
});
}
J'ai eu un problème similaire lorsque je voulais obtenir un rapport d'échec peu plus significatif. Je comparais les collections et utilisais un nombre incorrect d'éléments - aucune idée de la raison réelle de l'échec. Malheureusement, j'ai fini par écrire un code de comparaison manuellement - donc vérifier toutes les conditions, puis faire une seule affirmation à la fin avec un bon message d'erreur.
Je sais que votre question a été posée il y a plusieurs années. Mais récemment (environ 2017 ou 2018), Nunit 3 soutient les avertissements. Vous pouvez intégrer un test [booléen] dans une affirmation. Mais au lieu de la ligne d'affirmation unique échouant à l'ensemble du test, le test fonctionnant enregistre l'avertissement et continuera sur le test.
Lire à ce sujet ici: https: //docs.nunit. Org / Articles / Nunit / Tests d'écriture / AVERTISSEMENTS.HTML
Il se comporte de la même manière à plusieurs (énumérés par @yann Trevin ci-dessus et plusieurs sont également disponibles dans Nunit 3.0). La différence sympathique s'effectue bien que sur les tests d'intégration où avoir la flexibilité d'utiliser des commandes d'affirmation autonome. Contraste avec un groupe affirme dans une instance multiple. Une fois que l'affirmation multiple est terminée, le test peut ne pas continuer.
Tests d'intégration, en particulier ceux qui peuvent courir pendant des heures, testent peut-être à quel point un groupe de services Microsics joue tous ensemble, coûte cher à réexécuter. De plus, si vous avez plusieurs équipes (externes, internes, internes, infernales et éternelles) et de Timezones commettant du code pratiquement tout le temps, il peut être difficile d'obtenir un nouveau produit pour exécuter un test d'intégration de bout en bout la voie à la fin de son flux de travail une fois que toutes les pièces sont hébergées. (Note - Il est important d'assembler des équipes avec de nombreuses connaissances sur le domaine et au moins des connaissances en génie logiciel pour assembler des "contrats" solides pour la manière dont chaque API sera, et la gérer bien. Cela devrait donc aider à atténuer les incompatibles impliquées ci-dessus.)
Le test simple noir / blanc, passe-passe / échec est absolument correct pour les tests d'unités.
Mais comme les systèmes deviennent plus abstraits, superposés sur le service après service, agent après agent, la capacité de connaître une robustesse et une fiabilité des systèmes deviennent plus importantes. Nous savons déjà que les petits blocs du code fonctionneront comme prévu; Les tests d'unité et la couverture de code nous leur dit. Mais quand ils doivent tous courir au sommet de l'infrastructure de quelqu'un d'autre (AWS, Azure, Cloud Google), les tests unitaires ne sont pas suffisamment bons.
Savoir combien de fois un service a dû réessayer pour passer à travers, combien coûte un service, le système rencontrera-t-il la SLA compte tenu de certaines charges? Ce sont des tests d'intégration des choses peut vous aider à trouver l'utilisation du type d'affirmation que vous demandiez à propos de @Dnatoli.
Compte tenu du nombre d'années depuis votre question, vous êtes presque certainement un expert en maintenant.
Les tests unitaires peuvent être plus noirs et blancs que quelque chose comme des tests d'intégration, mais si vous utilisiez un outil tel que Speck Flow, vous aurez peut-être besoin du cadre de test pour vous donner un avertissement ou affirmer non concluant ...
Pourquoi certains cadres de test unitaire vous permettent-ils d'affirmer peu concluant s'il est noir et blanc?
Imaginez que la date de test de celle-ci que vous passez dans votre test d'unité est créée à partir d'un générateur de données aléatoire ... peut-être que vous en avez plusieurs de ces ... pour une condition de données, vous êtes sûr que c'est un échec pour Un autre jour pour condition que vous puissiez ne pas être sûr ...
Le point d'un avertissement ou d'une certaine non concluante consiste à dire à l'ingénieur de jeter un coup d'œil à ce cas d'angle et ajoutez plus de code pour tenter de l'attraper la prochaine fois ...
L'hypothèse que votre test sera toujours parfaite ou noir et blanc, je ne pense pas que ce soit correct, je rencontre trop de cas et 15 ans de test où il n'est pas passé ni échoué ... il passe ... échoue ... et je ne sais pas encore ... Vous devez penser au fait que lorsque vous échouez un test, cela signifie que vous savez que cela a échoué ...
De fausses échecs sont vraiment mauvais dans des tests automatisés ... Cela crée beaucoup de bruit ... Vous préférez dire que je ne sais pas si vous ne savez pas que vous échouez ...
Pouvez-vous mieux expliquer votre scénario? On dirait que vous pourriez faire quelque chose que je pourrais vous conseiller.
Mis à jour avec le contexte. Je connais sa meilleure pratique pour faire tester votre unité Pass Green Red Fauchée, cependant, dans ce cas, lorsqu'il y a un bug connu de faible priorité, l'ordre d'affirmation pourrait signifier qu'il cache un bug de priorité plus élevée.
Si vous avez un bug connu, vous devriez avoir un test d'échec. Si vous souhaitez ignorer le bogue, effectuez un test en double ou similaire et retirez l'affirmation qui court-circuiter le test de test afin que vous puissiez tester ce que vous voulez réellement faire.