Comment puis-je spécifier les paramètres de la méthode d'essai avec TestDriven.NET?

Question

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

[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 de code dur ou les mettre dans un fichier. En fait, je ne veux pas les écrire partout , je veux être invité chaque fois que je lance le test.

Quand 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 me attendais TestDriven.NET pour afficher une invite pour que je puisse entrer dans les valeurs, mais il n'a pas ...

Désolé si ma question semble stupide, la réponse est probablement très simple, mais je ne pouvais pas trouver quelque chose d'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 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 testée

Tests unitaires MS ne permettent pas le passage des paramètres à des tests. Au lieu de cela, vous devez créer tests unitaires dicté par les données. Essayez le lien, il peut vous aider.

Comme je l'ai mentionné. Je ne voudrais pas déclarer les arguments de passage aux tests unitaires se bonnes pratiques.

---

Mise à jour: J'étais jeune :). Tenez compte de la réponse de Sarfraz plutôt sur la façon de passer des paramètres à des tests NUnit.

Answer 2

Utilisez l'attribut du TestCase.

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

Answer 3

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 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 4

Je suis d'accord avec les autres réponses que les arguments de passage ne peuvent pas être meilleures pratiques, mais ni d'informations d'identification ou de codage dur adresses de serveur qui peuvent changer à un moment donné.

Inspiré par la solution proposée en question, je l'ai lu simplement entrée de la console au lieu d'utiliser des boîtes d'entrée. Les arguments sont enregistrés dans un fichier. Lors du démarrage d'un des tests, le fichier est redirigé et à lire dans une fonction d'initialisation qui doit être appelée avant que tous les cas de test exécutés.

nunit tests.dll < test.config

Ceci permet d'éviter l'interaction de l'utilisateur et doit être exécutable par un script d'automatisation. Le seul inconvénient est que le mot de passe doit encore être sauvé quelque part, mais au moins il peut être sauvegardé sur la machine locale des testeurs et est facile à changer.

Ce fut un projet, où feuilles Excel contenant les essais (non tests unitaires par définition) ont été utilisés pour laisser les autres de créer des cas de test pour un projet de grand côté serveur sans changer de code. Il aurait été mauvais si tous les tests devaient être forcé dans un seul géant feuille Excel. De plus il n'y avait pas CI, à de nombreux environnements de test sur différents serveurs.