VS Team Test: Test d’unité .Net avec Excel comme source de données: échec de l’adaptateur

J’essaie de faire des tests unitaires avec Excel comme source de données. Je reçois l’exception suivante. Comment pouvons-nous corriger cela?

L’adaptateur de test unitaire n’a pas réussi à se connecter à la source de données ni à lire les données. Pour plus d’informations sur le dépannage de cette erreur, voir “Dépannage des tests d’unité pilotée par les données”.


[TestMethod] [Owner("Lijo ")] [TestProperty("TestCategory", "Developer"), DataSource("Microsoft.ACE.OLEDB.12.0", "Data Source=C:/Sheets/DataSheet.xlsx;Extended Properties=Excel 12.0;", "[Sheet1$]", DataAccessMethod.Sequential)] public void ChangePasswordTest() { int a = Convert.ToInt32(TestContext.DataRow[0]); //(int)Column.UserId int b = Convert.ToInt32(TestContext.DataRow[1]); int expectedResult = Convert.ToInt32(TestContext.DataRow[2]); MyClass myObj = new MyClass(1, "P@ssw0rd"); int actualResult = myObj.GetAdditionResult(a, b); Assert.AreEqual(expectedResult, actualResult, "The addition result is incorrect."); } 

Lectures:

  1. Unit Testing Error – L’adaptateur de test d’unité n’a pas réussi à se connecter à la source de données ni à lire les données.

  2. Problème de tests unitaires pilotés par les données

  3. Comment créer un script de démarrage et de nettoyage pour le projet de test Visual Studio?

  4. Comment l’équipe MSTEST / Visual Studio 2008 teste-t-elle l’ordre d’exécution des méthodes de test?

  5. Visual Studio 2010 Ultimate – Plan de génération de données définissant un type de données incorrect pour la colonne

  6. Comment devrais-je tester par unité une classe CRUD simple?

Résolu moi-même d’une manière différente. Les autres réponses sont les bienvenues.

Voir: Procédure pas à pas: utilisation d’un fichier de configuration pour définir une source de données http://msdn.microsoft.com/en-us/library/ms243192.aspx

  [TestMethod] [DeploymentItem("C:/Sheets/DataSheet.xlsx")] [DataSource("MyExcelDataSource")] public void ChangePasswordTest() { int a = Convert.ToInt32(TestContext.DataRow[0]); //(int)Column.UserId int b = Convert.ToInt32(TestContext.DataRow[1]); int expectedResult = Convert.ToInt32(TestContext.DataRow[2]); MyClass myObj = new MyClass(1, "P@ssw0rd"); int actualResult = myObj.GetAdditionResult(a, b); Assert.AreEqual(expectedResult, actualResult, "The addition result is incorrect."); } 

App.Config

   

Pour VS 2010, la version de TestTools utilisée est Version = 10.0.0.0.

J’ai effacé une même tâche aujourd’hui. Et après quelques maux de tête, j’ai pu résoudre sans app.config:

 [TestMethod] [DataSource("System.Data.OleDB", @"Provider=Microsoft.ACE.OLEDB.12.0; Data Source=C:\Sheets\DataSheet.xlsx; Extended Properties='Excel 12.0;HDR=yes';", "Sheet1$", DataAccessMethod.Sequential )] public void ChangePasswordTest() { //Arrange //Act //Assert } 

Si vous utilisez des fichiers Excel comme ressources dans votre testproject, vous devez définir la propriété Copier dans le répertoire de sortie du fichier sur Copy always ou Copy if newer . Et ajoutez l’atsortingbut DeploymentItem à votre test:

 [TestMethod] [DataSource("System.Data.OleDB", @"Provider=Microsoft.ACE.OLEDB.12.0; Data Source=.\DataSheet.xlsx; Extended Properties='Excel 12.0;HDR=yes';", "Sheet1$", DataAccessMethod.Sequential )] [DeploymentItem(".\DataSheet.xlsx")] public void ChangePasswordTest() { //Arrange //Act //Assert } 

Bien que cela ne soit pas à 100% lié à la question et peut-être un peu sortingvial, j’aimerais append mes deux sous sur ce sujet général (c’était la question la plus pertinente que j’ai pu trouver à poster).

Dans le projet sur lequel je travaille actuellement, je me suis rendu compte de la nécessité de réaliser des tests unitaires simples basés sur des données (par exemple, avec peut-être 20 lignes environ pour un test donné). Ma liste de souhaits pour un “framework” basé sur les données était:

  1. Intégration simple et conviviale dans Visual Studio Test Explorer
  2. Capacité à continuer à utiliser mes touches de raccourci clavier existantes pour exécuter / déboguer la méthode de test dans laquelle se trouve le curseur
  3. Pas de fichiers externes ou de bases de données à gérer (c.-à-d. Aucun “DataSources”)
  4. Prise en charge “native” en C # et Visual Studio, c.-à-d. Qu’aucun package supplémentaire n’est nécessaire

Malgré le souhait n ° 4, j’ai examiné des bibliothèques externes telles que xUnit et NUnit. Ils semblaient résoudre le souhait n ° 3, mais n’avaient pas fait du bon travail en ce qui concerne les souhaits n ° 1 et n ° 2.

Frustré par le manque de solution simple, j’ai décidé de mettre en place moi-même un assistant extrêmement basique basé sur les données:

  public static void DataDrivenTest(Action> testAction, List> dataRows) { foreach (var dataRow in dataRows) testAction(dataRow); } 

Je l’utilise comme ça:

  [TestMethod] public void Unit_Can_Add_Two_Numbers() { UnitTestUtilities.DataDrivenTest( dataRow => { // Tests a+b=c var a = (int)dataRow[0]; var b = (int)dataRow[1]; var c = (int)dataRow[2]; Assert.AreEqual(a + b, c); }, new List> { // Rows of arguments a,b,c respectively new List{1,2,3}, new List{4,5,9} }); } 

Bien que cela réponde à tous mes souhaits, il présente des inconvénients:

  1. Un casting est requirejs dans la définition de l’action de test (pourrait probablement être corrigé avec des arguments génériques)
  2. La mise à jour de l’ordre des arguments dans les lignes de données signifie que les accesseurs de la méthode d’action doivent également être mis à jour
  3. Clairement déconseillé pour les tests de grande envergure pilotés par les données (par exemple, cet assistant serait compliqué pendant plus de 20 lignes de test, par exemple)
  4. Manque clairement de “sophistication”, c’est-à-dire que je suis sûr que les bibliothèques comme xUnit ont des fonctionnalités géniales qui ne l’ont pas.
  5. Il exécute toutes les lignes en tant que test unitaire (c’est-à-dire qu’il n’existe pas de test unitaire ni de rapport distincts pour chaque ligne de données).

Quoi qu’il en soit, cela a résolu mon problème de base de manière simple. J’espère que cela aidera quelqu’un à la recherche d’une solution simple comme moi. Après tout, si vous constatez que vous avez besoin d’une tonne de lignes de test pour tester une méthode, il peut être utile d’envisager un refactor pour décomposer la fonction testée en composants plus petits (pour l’utiliser ensuite avec des simulacres / faux, une dependency injection, etc.). ).