VS Team Test: .NET Unit Testing with Excel as Data Source: Adapter Failed

Question

Estoy intentando hacer Unit Testing con Excel como fuente de datos. Recibo la siguiente excepción. ¿Cómo lo corregimos?

El adaptador de prueba de unidad no pudo conectarse a la fuente de datos o leer los datos. Para obtener más información sobre cómo solucionar este error, consulte " pruebas unitarias basadas en datos Solución de problemas"

---

[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<int>(expectedResult, actualResult, "The addition result is incorrect."); 

    } 

---

Lecturas:

1. Unit Testing Error - The unit test adapter failed to connect to the data source or to read the data

2. Data driven unit tests problem

3. How to create Startup and Cleanup script for Visual Studio Test Project?

4. How Does MSTEST/Visual Studio 2008 Team Test Decide Test Method Execution Order?

5. Visual Studio 2010 Ultimate - Data Generation Plan Setting Incorrect Data Type for Column

6. How should I unit-test a simple CRUD-class?

Answer 1

lo resolvió a mí mismo de una manera diferente. Otras respuestas son bienvenidas

Consulte: Tutorial: Uso de un archivo de configuración para definir una fuente de datos 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<int>(expectedResult, actualResult, "The addition result is incorrect."); 

    } 

app.config

<configuration> 


<configSections> 

<section name="microsoft.visualstudio.testtools" 
type="Microsoft.VisualStudio.TestTools.UnitTesting.TestConfigurationSection, Microsoft.VisualStudio.QualityTools.UnitTestFramework, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"/> 

</configSections> 



<connectionStrings> 

<add name="MyExcelConn" 
    connectionString="Dsn=Excel Files;dbq=C:/Sheets/DataSheet.xlsx;defaultdir=.; driverid=790;maxbuffersize=2048;pagetimeout=5" providerName="System.Data.Odbc" /> 

</connectionStrings> 


<microsoft.visualstudio.testtools> 


    <dataSources> 

     <add name="MyExcelDataSource" 
     connectionString="MyExcelConn" 
     dataTableName="Sheet1$" 
     dataAccessMethod="Sequential"/> 

    </dataSources> 


</microsoft.visualstudio.testtools> 

</configuration> 

Para VS 2010, TestTools versión utilizada es la versión 10.0.0.0 =

Answer 2

Abandoné una misma tarea hoy. Y después de algunos dolores de cabeza que fue capaz de resolver sin 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 utiliza archivos de Excel como recursos en su TestProject, usted tiene que fijar la copia a la propiedad de salida del directorio del archivo a Copy always o Copy if newer. Y añadir el atributo DeploymentItem a su prueba:

[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 

} 

Answer 3

Aunque no es 100% en relación con la pregunta y quizás algo trivial, me gustaría tirar mis dos centavos sobre este tema general (este fue el más relevante pregunta que pude encontrar para publicar en).

En el proyecto en el que estoy trabajando encontré la necesidad de realizar algunas pruebas unitarias simples basadas en datos (por ejemplo, con quizás 20 filas más o menos para una prueba determinada).Mi lista de deseos para un "marco" impulsado por los datos fue:

1. agradable y fácil integración en el Visual Explorador Studio Test
2. Capacidad para seguir usando mis teclas de atajo de teclado existentes para ejecutar/depurar el método de ensayo de el cual el cursor se encuentra
3. no hay archivos externos o bases de datos a tener que gestionar (es decir, sin "DataSources")
4. apoyo "nativo" en C# y Visual Studio, es decir, no hay paquetes adicionales necesarios

a pesar de deseo # 4 , Busqué en bibliotecas externas como xUnit y NUnit. Parecían resolver el deseo # 3, pero no hicieron un gran trabajo en los deseos # 1 y # 2.

Frustrado con la falta de una solución fácil, decidí poner en práctica un ayudante muy básica basada en datos a mí mismo:

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

lo uso como esto:

[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<List<object>> 
       { 
        // Rows of arguments a,b,c respectively 
        new List<object>{1,2,3}, 
        new List<object>{4,5,9} 
       }); 
    } 

A pesar de que cumple con todos de mis deseos anteriores, tiene desventajas:

1. Se requiere fundición dentro de la definición de la acción de prueba (podría pro Bably ser fijado con un poco de magia argumento genérico)
2. Actualización de la orden de los argumentos en las filas de datos significa que los descriptores de acceso en el método de acción también tienen que ser actualizado
3. Claramente no es apropiado para grandes pruebas basadas en datos (por ejemplo, esta ayuda sería desordenado durante más de, digamos, 20 filas de prueba)
4. claramente carece de "sofisticación", es decir, estoy seguro de que las bibliotecas como xUnit tienen algunas características cobardes que esto no tiene
5. Se ejecuta todas las filas como una prueba unitaria (es decir, no hay pruebas de unidad separadas e informes para cada fila de datos)

De todos modos, resolvió mi problema básico de una manera sencilla. Espero que ayude a alguien en busca de una solución sencilla como yo. Después de todo, si encuentra que necesita una tonelada de filas de prueba para probar un método, podría valer la pena considerar un refactor para descomponer la función bajo prueba en componentes más pequeños (y luego usarla junto con simulaciones/falsificaciones, inyección de dependencia, etc.)