Varios orígenes de datos

Artículo
05/03/2024

Varios orígenes de datos son útiles cuando se busca una expansión combinatoria de uno o varios orígenes de datos (DataSource basado en tablas, DataSource basado en PICT o DataSource basado en WMI).

Diseñar el diseño de pruebas para hacer un uso eficaz de esta característica es fundamental. Veamos con la ayuda de un ejemplo por qué esto es así. Supongamos que como parte de varios DataSource, quiere especificar dos orígenes de datos basados en tablas, un datasource basado en WMI y un origen de datos basado en PICT. Por motivos de argumento, supongamos que la primera tabla tiene 4 filas, la segunda tiene 5 filas, la consulta WMI devuelve 2 resultados y las combinaciones de datos PICT generaron 6 combinaciones en pares. TAEF aparecerá con una expansión combinatoria de estos conjuntos de parámetros. Esto significa que se invocará el método de prueba en cuestión (4 X 5 X 2 X 6 =) 240 veces! Aumentar el número de invocaciones del método de prueba con combinaciones variables de parámetros puede producir resultados que disminuyan hasta que vaya la cobertura de pruebas. Esto hace que sea importante diseñar la prueba mediante varios orígenes de datos con cuidado y pesando otras alternativas. A continuación se muestran algunos puntos que puede considerar:

Asegúrese de que agrega valor para tener varias tablas. Si no las necesita para ser independientes, puede encontrar una combinación eficaz de parámetros usted mismo.
Compruebe si puede usar un archivo de modelo PICT con restricciones, en lugar de varias tablas.
Compruebe si hay un valor para refactorizar el caso de prueba en varias pruebas y asociar subconjuntos de varios orígenes de datos con cada sub-prueba recién creada.

Especificar varios orígenes de datos

El aspecto clave aquí es cómo especificar dataSource. Echemos un vistazo al fragmento de código de nuestros ejemplos nativos y administrados.

Nativo

1   namespace WEX { namespace TestExecution { namespace Examples
2   {
3       class AdvancedDataDrivenTests
4       {
5           TEST_METHOD_SETUP(DataDrivenSetup);
6           TEST_METHOD_CLEANUP(DataDrivenCleanup);
7
8           TEST_CLASS(AdvancedDataDrivenTests)
9
10          BEGIN_TEST_METHOD(SecondTable)
11              TEST_METHOD_PROPERTY(L"DataSource", L"Table:AdvancedDataDrivenTests.xml#Table2;Table:CppTestLevelDataSource.xml#NestedTable")
12          END_TEST_METHOD()
13
14          BEGIN_TEST_METHOD(FirstTable)
15              TEST_METHOD_PROPERTY(L"DataSource", L"Table:AdvancedDataDrivenTests.xml#Table1;"
16                  L"PICT:PictDataSource.txt;" L"WMI:SELECT Location FROM Win32_StartupCommand")
17          END_TEST_METHOD()
18      };
19  } /* namespace Examples */ } /* namespace TestExecution */ } /* namespace WEX */

Vea las líneas 11, 15 y 16 en el ejemplo anterior. En general, el patrón que se debe seguir para especificar datasource es una lista separada por punto y coma de cada especificación de DataSource. La especificación también tendría un aspecto muy similar en el código administrado.

Administrado

[TestMethod]
[DataSource(@"Table:CSharpAdvancedDataDrivenTests.xml#FirstTable;
    WMI:SELECT ProcessId FROM Win32_Service WHERE Name='Themes'")]

public void First()
{
    Log.Comment("In CSharpAdvancedDataDrivenTests.First");
    String[] shapes = m_testContext.DataRow["Shape"] as String[];
    foreach (String shape in shapes)
    {
        Console.WriteLine("The shape is " + shape);
    }

    Int32[] lengths = m_testContext.DataRow["Length"] as Int32[];
    foreach (int length in lengths)
    {
        Console.WriteLine("The length is " + length.ToString());
    }

    String description = (String)m_testContext.DataRow["Description"];
    Boolean desktopInteract = (Boolean)m_testContext.DataRow["DesktopInteract"];
    UInt32 processId = (UInt32)m_testContext.DataRow["ProcessId"];
    Log.Comment("Themes service is running on process " + processId.ToString());
    Log.Comment("Themes service description: " + description);
}

Los ejemplos también muestran las formas de especificar varios orígenes de datos en varias líneas. Por supuesto, podría haber especificado dataSource en una sola línea (como se muestra a continuación), pero podría mejorar significativamente la legibilidad mediante las construcciones mostradas anteriormente.

Especificación de DataSource en una sola línea

[DataSource("Table:CSharpAdvancedDataDrivenTests.xml#FirstTable;WMI:SELECT ProcessId FROM Win32_Service WHERE Name='Themes'")]

Solo para volver a iterar: el método de prueba se ejecutará una vez para cada expansión combinatoria n-way de conjuntos de datos generados por cada dataSource individual. Por ejemplo, para el ejemplo administrado anterior, suponiendo de forma segura que solo se ejecute un servicio Temas y que sepa que hay 3 filas en el origen de datos de tabla proporcionado, el método de prueba se invocará 3 veces (1 X 3). En el caso de ejemplo nativo, en el método de prueba SecondTable, hay dos orígenes de datos de tabla especificados. La primera tabla contiene 3 filas y la segunda tabla contiene 4 filas. Por lo tanto, el método de prueba se invocará 12 veces (3 X 4).

Restricciones que se aplican al especificar varios orígenes de datos

Las restricciones solo son aplicables cuando se desea especificar un DataSource basado en tabla en las varias especificaciones de DataSource. Table DataSource debe especificarse como Table:<relative path to XML file>#<TableId>. Si TAEF detecta que "TableId" se proporciona como metadatos independientes, se supone que DataSource es un único DataSource basado en tabla y continúa.

Compartir a través de