J'écris des tests d'unité avec Nunit et le plugin Testdriven.net. J'aimerais fournir des paramètres à une méthode de test, comme celui-ci:
[Test, TestCaseSource("PromptCredentials")]
public void TestLogin(string userName, string password)
{
// ...
}
static object[] PromptCredentials
{
get
{
string userName = Interaction.InputBox("Enter user name", "Test parameters", "", -1, -1);
string password = Interaction.InputBox("Enter password", "Test parameters", "", -1, -1);
return new object[]
{
new object[] { userName, password }
};
}
}
4 Réponses :
Je pense que vous pouvez résoudre ce problème en utilisant le plugin Rowtest pour Nunit trouvé ici http://www.andreas-schlapsi.com/2008/01/29/rowtest-extension-120/
Vous pouvez créer des tests simples axés sur des données dans lesquels les données de test sont fourni par les attributs [ligne]. Voici donc un exemple de test qui passe encore et encore avec différents paramètres:
Merci pour votre réponse. Je pense que ce plugin est fabriqué obsolète par le test TestCaseattribute Nouveau dans Nunit 2.5 ( Nunit.org/index .php? p = TestCase & R = 2.5 ). Quoi qu'il en soit, cela ne résout pas mon problème: je ne veux pas savoir dedans mes informations d'identification. Je veux une invite à entrer manuellement lorsque le test est exécuté
Ah ok. J'ai mal compris. Ravi de savoir sur TestCaseattribute cependant :)
Les tests de l'unité MS ne permettent pas de passer des paramètres de test. Au lieu de cela, vous devez créer Tests de l'unité DataDentriven . Essayez le lien, cela peut vous aider.
Mise à jour: J'étais jeune :). Considérez la réponse de Sarfraz à la place sur la manière de passer des paramètres aux tests de Nunit. Les tests unitaires ne doivent normalement pas prendre de paramètres. Vous créez les données nécessaires dans le test lui-même.
Merci, mais encore une fois, cela ne résout pas mon problème ... Comment suis-je censé exécuter un test qui nécessite des informations d'identification? Je ne veux pas mettre mon nom d'utilisateur et mon mot de passe personnel dans un code qui sera partagé avec d'autres ...
Dans une telle affaire, utilisez des informations d'identification factice. Quel type de logique votre test de logique est-il censé couvrir s.t. Vous avez besoin de manipulation de crédits, etc.?
Oh, je lis maintenant votre poste édité. Ne pouvions-tu pas utiliser quelques références factices. Un test de test + passe qui a le droit d'accéder à ce que vous devez accéder? Bien que je ne sois pas tout à fait sûr si le genre de chose que vous souhaitez atteindre est vraiment ce qui devrait être testé par un test unitaire. Vérifiez ceci: Stackoverflow.com/Questtions/1257560/...
Le composant que je teste se connecte au forum de Vbulletin pour récupérer les cookies d'authentification. Peut-être que je pourrais créer un compte factice ... ou peut-être que vous avez raison et cela ne devrait même pas être un test unitaire;)
Comprendre ... Eh bien, c'est toujours un peu "discutable" Qu'est-ce que c'est et ce qui n'est pas un test d'unité. Dans votre cas, je dirais que ce n'est pas vraiment ce que je saisirais avec un test unitaire. Ce que je ferais, c'est de fournir un cookie d'authentification factice et de l'injecter en quelque sorte pour simuler un appel à Vbulletin. De cette façon, je testerais ce que ma logique fait avec un biscuit correct et quoi avec un mauvais. C'est dans mon œil ce qui devrait être capturé avec un test unitaire.
Juri et J.R. Garcia sont corrects. Vous voulez des tests automatisés sans surveillance - de cette façon, vous pouvez les exécuter à partir d'un serveur de construction, etc. Le moyen de le faire est d'utiliser une injection de dépendance avec un objet factice (Stub) qui gère votre authentification. Dans l'application réelle, vous injectez le schéma d'authentification VRAI (implémentation de la même interface).
Utilisez le Attribut TestCase .
[TestCase("User1", "")]
[TestCase("", "Pass123")]
[TestCase("xxxxxx", "xxxxxx")]
public void TestLogin(string userName, string password)
{
// ...
}
+1. C'est bien mieux que la réponse choisie en manipulant une injection de dépendance dans les paramètres TESTCASE () au lieu de perrocher «aucun argument dans la méthode». Malheureusement, je ne pense pas que MS Unitaire test ait quelque chose comme ça, juste Nunit
C'est la réponse correcte et courte. Peu importe que cela soit une bonne ou une bonne pratique.
Veuillez marquer cela comme la bonne réponse. Cela répond à la question et à moi n'est pas une mauvaise pratique d'utiliser des paramètres en général. Pour les mots de passe, je serais moins enclin.
Je suis d'accord avec les autres réponses selon lesquelles les arguments qui transmettent ne sont peut-être pas les meilleures pratiques, mais aucune des informations d'identification du codage dur ou des adresses de serveur pouvant changer à un moment donné.
Inspiré par la solution suggérée en question, je lis simplement la saisie de la console au lieu d'utiliser des zones d'entrée. Les arguments sont enregistrés dans un fichier. Lors du démarrage des tests, le fichier est redirigé et doit être lu à partir de certaines fonctions d'initialisation à appeler avant tout cas de test de test. Ceci évite l'interaction de l'utilisateur et devrait être Runnable par n'importe quel script d'automatisation. L'inconvénient est que le mot de passe doit toujours être sauvegardé quelque part, mais au moins il peut être enregistré local sur la machine de testeurs et est facile à changer. Ceci était pour un projet, où des feuilles Excel contenant les tests (non des tests d'unités par définition) ont été utilisées pour permettre aux autres de créer des cas de test pour un plus grand projet côté serveur sans changer de code. Cela aurait été mauvais si tous les cas de test devaient être forcés dans une seule feuille Excel géante. En outre, il n'y avait pas de CI, juste de nombreux environnements de test sur différents serveurs.
Je pense que si vous faites cela, vous aurez du mal à exécuter vos tests automatiquement dans un environnement CI (intégration continue).
Vous avez absolument raison. Cependant, c'est un petit projet communautaire, de sorte que CI n'est pas vraiment un problème, du moins pour le moment.