J'utilise Nunit de C # et .NET Core pour faire des tests matériels / de production sur certains composants électroniques. Les cas de test stimulent le matériel de différentes manières et, pour vérification finale, j'allume une LED. C'est un peu difficile à vérifier automatiquement (sans construire de matériel personnalisé), donc je veux avoir une étape de vérification manuelle pour que l'utilisateur dise «réussite ou échec» si le voyant est allumé ou non. Est-ce même possible dans Nunit?
J'ai essayé d'utiliser Console.ReadLine () / Console.ReadKey () qui ne fonctionne pas. Y a-t-il un moyen de faire en sorte que cela fonctionne ou existe-t-il des alternatives à cela?
L'autre option que j'ai est de mettre cette étape manuelle en dehors du cadre Nunit, par exemple dans un script shell. Mais alors je perdrais les avantages de la gestion des résultats et plus encore. Des recommandations à ce sujet?
3 Réponses :
Bien sûr, il est possible de pirater nuint, mais cette "fonctionnalité" en vaut-elle la peine? Je pense que ce sera malodorant et vous coûtera à vous / vos collègues plus de ressources au support, car il n'y a pas de solution de contournement facile ici. Je vous suggère de séparer la logique en deux:
Un pour semi-automatique (c.-à-d. test manuel) qui se présente comme une simple application de console avec des questions et des réponses d'experts (y a-t-il une LED allumée / éteinte? une étincelle sort? une banque d'alimentation a explosé?).
L'autre pour les tests automatiques (NUnit, ou peu importe) sous forme de simple DLL.
L'avantage de cette approche, vous pouvez exécuter un test automatique à partir d'une application de console semi-automatique à un moment donné (probablement au début), et vous pouvez facilement interagir avec un expert.
NUnit et d'autres frameworks de test sont conçus pour effectuer des tests unitaires.
Une unité est définie par Wikipedia comme
Les tests unitaires sont généralement des tests automatisés écrits et exécutés par un logiciel développeurs pour s'assurer qu'une section d'une application (connue sous le nom de "unit") répond à sa conception et se comporte comme prévu.
Fondamentalement, ce que vous voulez faire n'est donc pas un test unitaire, c'est plutôt un test d'intégration car vous voulez tester si deux domaines distincts distincts de la solution fonctionnent ensemble, à savoir le logiciel et le matériel. p>
Par conséquent, ce n'est pas vraiment ce pour quoi NUnit, ou des frameworks de tests unitaires similaires, ont été conçus.
Par conséquent, utilisez NUnit pour tester la partie logicielle, puis regardez d'autres options pour les tests d'intégration, ce qui peut signifier écrire d'autres outils ou même simplement le faire manuellement!
Merci. En pratique cependant, ce qui définit une "unité" varie considérablement. J'ai travaillé plus de 10 ans en utilisant différents frameworks de tests unitaires conçus pour des unités plus petites, pour faire des tests d'intégration et des tests matériels. C'est la première fois que j'utilise nunit.
NUnit ne fonctionne pas vraiment avec une console - et en fait, vous ne devriez pas l'utiliser pour tester quelque chose qui nécessite une interaction de l'utilisateur - qui serait un test d'intégration. Bien que vous puissiez l'implémenter:
if(Double.TryParse(Console.ReadLine(), out var ok) && ok)
Assert.Pass("Test OK");
else
Assert.Fail("Test failed");
Je doute que ce soit une bonne idée car il est impossible d'automatiser - ce qui est l'un des principaux objectifs des tests unitaires.
Comme tout ce que vous voulez semble être un marqueur pour NUnit si ou sinon votre test a réussi, j'utiliserais toujours Assert.Inconclusive pour indiquer qu'un utilisateur doit le faire manuellement interpréter le résultat (par exemple un fichier) d'une manière ou d'une autre. En fait, vous pouvez complètement ignorer NUnit pour ce type de test, démarrez simplement votre application et laissez votre utilisateur l'utiliser comme d'habitude.
De plus, rédigez des tests unitaires pour tout ce qui est testable. Refactorisez votre code si nécessaire afin d'obtenir quelque chose de testable, qui extrait la logique métier de votre interface utilisateur.
Merci! De nombreux frameworks de tests unitaires sont également de bons frameworks de tests généraux (utilisables pour les tests d'intégration, manuels, matériels, etc.). Ce n'est apparemment pas le cas avec Nunit, car cette "fonctionnalité" fait défaut. Je vais très probablement faire une application console / shell qui appelle les fonctionnalités de test unitaire pour les tests automatiques, puis implémenter la vérification manuelle séparément.
Je ne pense pas que NUnit soit une bonne solution ici. Une application console simple suffira pour l'interaction. Mieux vaut laisser les choses aussi simples que possible - séparez votre logique en interactive et non interactive.
Voulez-vous simplement une option manuelle "ce test était OK / pas OK" pour indiquer un test vert ou rouge? Alors ne comptez pas sur NUnit pour le résultat, exécutez simplement votre console comme d'habitude sans NUnit.
@HimBromBeere: oui, en gros.