Comment spécifier les paramètres de la méthode de test avec TestDriven.NET?

Question

J'écris des tests unitaires avec NUnit et le plugin TestDriven.NET. Je voudrais fournir des paramètres à une méthode d'essai comme celui-ci:

[TestFixture] 
public class MyTests 
{ 
    [Test] 
    public void TestLogin(string userName, string password) 
    { 
     // ... 
    } 

    ... 
} 

Comme vous pouvez le voir, ces paramètres sont des données privées, donc je ne veux pas à coder en dur ou les mettre dans un fichier. En fait, je ne veux pas les écrire n'importe où, je veux être invité chaque fois que je lance le test.

Lorsque je tente de lancer ce test, je reçois le message suivant dans la fenêtre de sortie:

TestCase 'MyProject.MyTests.TestLogin' inexécution: Aucun argument n'a été fourni

Alors Ma question est, comment puis-je fournir ces paramètres? Je m'attendais à ce que TestDriven.NET affiche une invite pour que je puisse saisir les valeurs, mais pas ...

Désolé si ma question semble stupide, la réponse est probablement très simple, mais je n'ai rien trouvé utile sur Google ...

---

EDIT: Je viens de trouver un moyen de le faire, mais il est un sale tour ...

[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 } 
      }; 
     } 
    } 

Je suis toujours intéressé par une meilleure solution ..

Answer 1

tests unitaires ne doivent normalement pas prendre de paramètres. Vous créez les données nécessaires dans le test lui-même.

• La valeur attendue
• Vous appelez votre méthode que vous voulez tester passer les arguments nécessaires
• Vous comparez le résultat avec la valeur attendue et la valeur retournée par votre méthode éprouvée

MS Les tests unitaires ne permettent pas de passer des paramètres aux tests. Au lieu de cela, vous devez créer Datadriven Unit tests. Essayez le lien, cela peut vous aider.

Comme je l'ai mentionné. Je ne dirais pas que passer des arguments aux tests unitaires est une bonne pratique.

---

Mise à jour: j'étais jeune :). Considérez plutôt la réponse de Sarfraz sur comment passer des paramètres aux tests NUnit.

Answer 2

Je pense que vous peut 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 de simples tests de données Driven où les données de test est fourni par [ligne] attributs. Voici donc un exemple d'un test qui est exécuté maintes et maintes fois avec des paramètres différents:

[TestFixture] 
public class RowTestSample 
{ 
[RowTest] 
[Row(1000, 10, 100.0000)] 
[Row(-1000, 10, -100.0000)] 
[Row(1000, 7, 142.85715)] 
[Row(1000, 0.00001, 100000000)] 
[Row(4195835, 3145729, 1.3338196)] 
public void DivisionTest(double numerator, double denominator, double result) 
{ 
    Assert.AreEqual(result, numerator/denominator, 0.00001); 
} 
} 

Answer 3

Utilisez l'attribut TestCase.

[TestCase("User1", "")] 
[TestCase("", "Pass123")] 
[TestCase("xxxxxx", "xxxxxx")] 
public void TestLogin(string userName, string password) 
{ 
    // ... 
} 

Answer 4

Je suis d'accord avec les autres réponses que les arguments de passage ne peuvent pas être meilleures pratiques, mais ni les informations d'identification est difficile de codage ou les adresses de serveur qui peuvent changer à un moment donné. Inspiré par la solution suggérée en question, je lis simplement l'entrée de la console au lieu d'utiliser des boîtes de saisie. Les arguments sont enregistrés dans un fichier. Lors du démarrage des tests, le fichier est redirigé et lu à partir de la fonction d'initialisation qui doit être appelée avant l'exécution de chaque cas de test.

nunit tests.dll < test.config 

Cela évite l'interaction de l'utilisateur et devrait pouvoir être exécuté par n'importe quel script d'automatisation. Inconvénient est que le mot de passe doit encore être enregistré quelque part, mais au moins, il peut être enregistré localement sur la machine testeurs et est facile à changer. Il s'agissait d'un projet où des feuilles Excel contenant les tests (et non des tests unitaires par définition) étaient utilisées pour permettre à d'autres de créer des cas de test pour un projet côté serveur plus important sans modification de code. Il aurait été mauvais si tous les cas de test devaient être forcés dans une seule feuille géante d'Excel. En outre, il n'y avait pas de CI, juste de nombreux environnements de test sur différents serveurs.