Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
El comando run-compare de PQTest es una herramienta eficaz para las pruebas de regresión, lo que le permite evaluar exhaustivamente las funciones del conector y la generación de texto del comando. Para ilustrar su versatilidad, las secciones posteriores proporcionan varios ejemplos adaptados a diferentes escenarios.
Nota:
El comando run-compare reemplaza al comando compare anterior.
Formatos de entrada de prueba
El comando run-compare admite dos formatos de entrada de prueba:
-
Formato de expresión: expresión M única (por ejemplo, una
letexpresión o invocación de función). Este formato es el formato más sencillo y es adecuado para la mayoría de los escenarios de prueba. - Formato de documento de sección: M documento de sección que contiene uno o varios miembros de sección. Este formato es útil para las pruebas que requieren funciones auxiliares, valores compartidos o configuraciones más complejas.
Cuando un archivo de prueba usa el formato de expresión, PQTest lo convierte automáticamente en un documento de sección internamente antes de la evaluación. También puede escribir la entrada de prueba directamente como un documento en secciones.
Ejemplo de formato de expresión
let
Source = Contoso.Contents("TestEndpoint"),
Result = Table.RowCount(Source)
in
Result
Ejemplo de formato de documento de sección
section Test;
shared Helper = (x) => x + 1;
shared Query = let
Source = Contoso.Contents("TestEndpoint"),
Result = Helper(Table.RowCount(Source))
in
Result;
Cuando se proporciona una consulta de parámetros, la consulta de parámetros se agrega como miembro de sección al documento de sección. La consulta de parámetros se evalúa como parte de la misma sección, lo que permite que la consulta de prueba haga referencia a ella directamente.
Consultas básicas
La forma más sencilla de realizar pruebas es agregar una expresión de consulta única a un .query.pq archivo, que puede ejecutar mediante el comando run-compare . PQTest evalúa la expresión y genera un .pqout archivo (salida) con el mismo nombre. Para las ejecuciones posteriores, compara la salida generada a partir de la evaluación del archivo .query.pq con el archivo .pqout del mismo nombre y devuelve la salida de la evaluación.
Ejemplo 1: Ejecución del comando run-compare para un archivo de consulta cuando no existe un archivo de salida
En el ejemplo siguiente se ejecuta un único archivo de prueba de consulta mediante la extensión de Power Query especificada y se genera un archivo de salida que se va a comparar.
<Path to PQTest.exe>.\PQTest.exe run-compare -e contoso.mez -q contoso.query.pq
[
{
"Details": "Contoso.Contents(\"TestEndpoint\")",
"EndTime": "2025-12-11T18:04:14.8991822+00:00",
"Method": "Compare.TestFiles",
"Name": "contoso.query.pq",
"StartTime": "2025-12-11T18:04:11.1532388+00:00",
"Output": [
{
"SourceFilePath": "contoso.query.pq",
"OutputFilePath": "contoso.query.pqout",
"Status": "Output File Generated",
"SerializedSource": null,
"SourceError": null,
"OutputError": null
}
],
"Status": "Passed",
"Type": "PQTest.Expression"
}
]
Ejemplo 2: ejecución del comando run-compare para un archivo de consulta cuando no existe un archivo de salida y se establece la marca FailOnMissingOutputFile
<Path to PQTest.exe>.\PQTest.exe run-compare -e contoso.mez -q contoso.query.pq -fomof
[
{
"Details": "Contoso.Contents(\"TestEndpoint\")",
"EndTime": "2025-12-11T18:04:14.8991822+00:00",
"Method": "Compare.TestFiles",
"Name": "contoso.query.pq",
"StartTime": "2025-12-11T18:04:11.1532388+00:00",
"Output": [
{
"SourceFilePath": "contoso.query.pq",
"OutputFilePath": "contoso.query.pqout",
"Status": "Missing Output File",
"SerializedSource": "Output of contoso.query.pq",
"SourceError": null,
"OutputError": null
}
],
"Status": "Failed",
"Type": "PQTest.Expression"
}
]
Ejemplo 3: Ejecución del comando run-compare para un archivo de consulta con un archivo de salida presente
En el ejemplo siguiente se ejecuta un único archivo de prueba de consulta mediante la extensión de Power Query especificada, se compara con el archivo de salida y se devuelve el resultado.
<Path to PQTest.exe>.\PQTest.exe run-compare -e contoso.mez -q contoso.query.pq
[
{
"Details": "Contoso.Contents(\"TestEndpoint\")",
"EndTime": "2025-12-11T18:04:14.8991822+00:00",
"Method": "Compare.TestFiles",
"Name": "contoso.query.pq",
"StartTime": "2025-12-11T18:04:11.1532388+00:00",
"Output": [
{
"SourceFilePath": "contoso.query.pq",
"OutputFilePath": "contoso.query.pqout",
"Status": "Passed",
"SerializedSource": null,
"SourceError": null,
"OutputError": null
}
],
"Status": "Passed",
"Type": "PQTest.Expression"
}
]
Prueba con consulta de parámetros
La consulta de parámetros es una consulta que se combina con una consulta de prueba en tiempo de ejecución, con la consulta de parámetros que se ejecuta primero. Esta funcionalidad le permite dividir el archivo ".query.pq" en dos partes: el archivo de consulta de parámetros y el archivo de consulta de prueba.
Pruebas de orígenes de datos independientes con parámetros y formato de consulta de prueba
Un ejemplo de caso de uso en el que esta funcionalidad sería útil es crear un conjunto de pruebas independiente del origen de datos. Puede usar la consulta de parámetros para recuperar datos del origen de datos y hacer que la consulta de prueba sea M genérica. Si desea ejecutar las pruebas para otro conector, solo tiene que agregar o actualizar la consulta de parámetros para que apunte a ese origen de datos específico.
Una diferencia clave al usar una consulta de parámetros es que la consulta de prueba sigue un formato diferente. En lugar de ser una expresión de fórmula, debe ser una función M que toma un parámetro de entrada, que representa la tabla devuelta desde la consulta de parámetros.
Cuando se proporciona una consulta de parámetros, la consulta de parámetros se agrega como miembro de sección al final del documento de sección de la prueba. Las entradas de prueba y de parámetro se evalúan conjuntamente como un único documento de la sección Mashup.
Nota:
Si el archivo de consulta de parámetros contiene errores (por ejemplo, errores de sintaxis o errores de evaluación), PQTest notifica un error descriptivo que indica el problema con el archivo de parámetros en lugar de producir un error poco claro.
Supongamos que tienes la siguiente consulta de prueba:
let
Source = Snowflake.Databases("...", "..."),
Database = Source{[Name="...",Kind="Database"]}[Data],
SelectColumns = Table.RemoveColumns(Database, { "Data" })
in
SelectColumns
Para convertirlo en una consulta de prueba y parámetros, debe dividirlos de la siguiente manera:
Consulta de parámetros:
let
Source = Snowflake.Databases("...", "..."),
Database = Source{[Name="...",Kind="Database"]}[Data],
Schema = Database{[Name="...",Kind="Schema"]}[Data],
Taxi_Table = Schema{[Name="...",Kind="Table"]}[Data]
in
Taxi_Table
Consulta de prueba:
(Source) => let
SelectColumns = Table.RemoveColumns(Source, { "VendorID" })
in
SelectColumns
Ejemplo 4: Uso de la consulta de parámetros y la consulta de prueba con el comando run-compare
<Path to PQTest.exe>.\PQTest.exe run-compare -e contoso.mez -q contoso.query.pq -pa contoso.parameter.pq
[
{
"Details": "(Source) => let\r\n Schemas = Table.RemoveColumns(Source, { \"Data\" })\r\nin\r\n Schemas",
"EndTime": "2025-12-11T18:04:14.8991822+00:00",
"Method": "Compare.TestFiles",
"Name": "contoso.query.pq",
"StartTime": "2025-12-11T18:04:11.1532388+00:00",
"Output": [
{
"SourceFilePath": "contoso.query.pq",
"OutputFilePath": "contoso.query.pqout",
"Status": "Passed",
"SerializedSource": null,
"SourceError": null,
"OutputError": null
}
],
"Status": "Passed",
"Type": "PQTest.Expression"
}
]
Comparación de diagnósticos
Se puede evaluar información de diagnóstico adicional al usar el comando run-compare mediante la suscripción a un canal de diagnóstico. Cuando se ejecuta el comando run-compare , PQTest genera un .diagnostics archivo para cada canal suscrito que tenía un evento. En el caso de las ejecuciones posteriores, compara el diagnóstico con su archivo .diagnostics, similar a .pqout.
Ejemplo 5: suscripción al canal de diagnóstico ODBC (conectividad abierta de base de datos) para validar el plegado de consultas
En el ejemplo siguiente se muestra cómo suscribirse al canal ODBC, que captura cualquier SQL generado por el controlador ODBC cuando se usa el plegado de consultas.
<Path to PQTest.exe>.\PQTest.exe run-compare -e contoso.mez -q contoso.query.pq -dc "Odbc"
El canal de diagnóstico ODBC se puede usar para comprobar que una consulta está plegada y que está generando el SQL correcto.
let
Source = AzureSpark.Tables("..."),
T1 = Source{[Schema="default",Item="DATABASE"]}[Data],
SelectColumns = Table.Group(T1, {}, {{"Maximum", each List.Max([number_column]), type number}}),
FirstN = Table.FirstN(SelectColumns, 1)
in
FirstN
La consulta ahora plega y genera el siguiente texto de comando ODBC en el .diagnostics archivo:
[
{
"Command": "DESCRIBE default.DATABASE;"
},
{
"Command": "select top 1 max(`number_column`) as `C1` from `SPARK`.`default`.`DATABASE`"
}
]
Uso de un archivo de configuración
Cualquier parámetro de entrada de línea de comandos para el comando run-compare también se puede pasar a través de un archivo de configuración JSON. Json puede tener las siguientes opciones:
| Option | Tipo | Description |
|---|---|---|
| ExtensionPaths | array | Matriz de rutas de acceso que apuntan al archivo del conector (mez/pqx). |
| FailOnMissingOutputFile | bool | La comparación de ejecución no genera un archivo PQOut y produce un error si no existe. |
| FailOnFoldingFailure | bool | Se produce un error en la comparación de ejecución si una consulta no se plega por completo. Cuando está habilitada, las consultas que no se pueden plegar completamente al origen de datos generan un error en lugar de revertir a la evaluación local. |
| ParameterQueryFilePath | string | Archivo de consulta que contiene expresiones M, que se combina en tiempo de ejecución con el archivo de consulta de prueba. Un caso de uso común es tener un único archivo de consulta de parámetros para especificar una expresión M para recuperar los datos de varias consultas de prueba. |
| QueryFilePath | string | Archivo de consulta que contiene la expresión M (.pq) que se va a probar. |
| TrxReportPath | string | Genera un archivo TRX (archivo de resultados de pruebas de Visual Studio) y archivos JSON independientes para cada prueba en una ruta de acceso determinada. |
| DiagnosticChannels | array | Nombre de los canales de diagnóstico que se van a adjuntar a la ejecución de pruebas (por ejemplo, Odbc para capturar instrucciones de plegado de consultas). |
| CarpetaDeResultadosDePruebasIntermedias | string | Ruta de acceso de carpeta personalizada para almacenar resultados intermedios de pruebas. |
| PersistirResultadosDePruebaIntermedios | bool | Mantiene los resultados intermedios de las pruebas una vez completada la ejecución de la prueba. |
En caso de que se proporcionen tanto la entrada en la línea de comandos como la opción de configuración, se da prioridad a la entrada en la línea de comandos.
Ejemplo 6: Uso del archivo de configuración en lugar de argumentos de la línea de comandos
<Path to PQTest.exe>.\PQTest.exe run-compare -e contoso.mez -q contoso.query.pq -fomof
El comando es equivalente al siguiente comando:
<Path to PQTest.exe>.\PQTest.exe run-compare -sf settings.json
Donde settings.json es el siguiente archivo JSON:
{
"ExtensionPaths": ["contoso.mez"],
"QueryFilePath": "contoso.query.pq",
"FailOnMissingOutputFile": true
}
Probar baterías con el comando run-compare
Una batería de prueba es una colección de pruebas que evalúan varios aspectos del código. Coloque los archivos de consulta en la misma carpeta para que PQTest pueda localizarlos fácilmente. En lugar de pasar un nombre de archivo de prueba específico, especifique la ruta de acceso de la carpeta y PQTest ejecuta todos los archivos de consulta de prueba .query.pq en un solo paso.
Ejemplo 7: Ejecución de una batería de pruebas
Suponiendo que una carpeta denominada test contenga los siguientes archivos:
- contoso.testa.query.pq
- contoso.testb.query.pq
- contoso.testc.query.pq
Toda la batería de prueba se puede ejecutar mediante la siguiente línea de comandos:
<Path to PQTest.exe>.\PQTest.exe run-compare -e contoso.mez -q .\test
Omitir pruebas al ejecutar una batería de pruebas
Se puede omitir una prueba al ejecutar una batería de pruebas cambiando la extensión del archivo .query.pq a .query.pq.ignore.
Ejemplo 8: Omitir una prueba al ejecutar una batería de pruebas
Suponiendo que una carpeta denominada test contenga los siguientes archivos:
- contoso.testa.query.pq
- contoso.testb.query.pq.ignore
- contoso.testc.query.pq
Los archivos contoso.testa.query.pq y contoso.testc.query.pq se ejecutan, pero contoso.testb.query.pq.ignore se omite cuando se ejecuta el siguiente comando para ejecutar la batería de prueba:
<Path to PQTest.exe>.\PQTest.exe run-compare -e contoso.mez -q .\test
Filtrado de pruebas
La --testFilter opción permite incluir o excluir de forma selectiva archivos de prueba al ejecutar baterías de prueba. Esta opción usa patrones globales para buscar coincidencias con las rutas de acceso de archivo y se puede especificar varias veces para crear reglas de filtrado complejas.
Filtros de inclusión
Especifique qué archivos incluir en la ejecución de la prueba usando patrones glob estándar.
<Path to PQTest.exe>.\PQTest.exe run-compare -e contoso.mez -q .\test --testFilter "Suite1/**/*.pq"
Filtros de exclusión
Especifique los archivos que se van a excluir de la ejecución de pruebas mediante el ! prefijo para indicar patrones de exclusión.
<Path to PQTest.exe>.\PQTest.exe run-compare -e contoso.mez -q .\test --testFilter "!BrokenTests/*"
Varios filtros
Se pueden combinar varias --testFilter opciones para crear lógica de filtrado compleja:
<Path to PQTest.exe>.\PQTest.exe run-compare -e contoso.mez -q .\test --testFilter "**/*.pq" --testFilter "!BrokenTests/*" --testFilter "!**/*donotrun*.pq"
Comportamiento de filtro
-
Inclusión implícita: cuando no se especifica ningún filtro de inclusión,
**/*.query.pqse aplica automáticamente. - Sin distinción entre mayúsculas y minúsculas: todos los patrones coinciden sin considerar mayúsculas o minúsculas.
- Orden independiente: el orden de los filtros no afecta al resultado.
-
Formato de ruta: use barras diagonales (
/) en patrones para la compatibilidad multiplataforma.
Ejemplos de patrones de Glob
| Pattern | Description |
|---|---|
**/*.pq |
Todos los .pq archivos de cualquier directorio |
**/*.query.pq |
Todos los .query.pq archivos de cualquier directorio |
Suite1/**/*.pq |
Todos los .pq archivos del directorio Suite1 |
**/test*.pq |
Todos los .pq archivos que comienzan con "test" |
!BrokenTests/* |
Exclusión de todos los archivos en el directorio BrokenTests |
!**/*temp*.pq |
Excluir todos los .pq archivos que contienen "temp" |
SpecificTest.pq |
Incluir solo el archivo específico |
Nota:
Los filtros se aplican a la ruta de acceso relativa desde el directorio de consulta especificado. Se devuelve un error si se proporcionan filtros y la ruta de acceso del archivo de consulta apunta a un archivo específico en lugar de a un directorio. Use comillas alrededor de patrones para evitar la expansión del shell.
Enumeración de archivos de prueba sin ejecución
La --listOnly opción permite obtener una vista previa de los archivos de prueba que ejecutaría el comando run-compare sin ejecutar realmente las pruebas. Esta opción es útil para comprobar el comportamiento del filtro y la detección de pruebas.
Ejemplo 9: Enumeración de archivos de prueba
<Path to PQTest.exe>.\PQTest.exe run-compare -e contoso.mez -q .\test --listOnly
{
"SourcePath": "C:\\MyProject\\test",
"TestFilters": [],
"Tests": [
{
"Test": "MyTest.query.pq",
"RelativePath": "Suite1\\MyTest.query.pq",
"AbsolutePath": "C:\\MyProject\\test\\Suite1\\MyTest.query.pq"
},
{
"Test": "AnotherTest.query.pq",
"RelativePath": "Suite2\\AnotherTest.query.pq",
"AbsolutePath": "C:\\MyProject\\test\\Suite2\\AnotherTest.query.pq"
}
]
}
La salida contiene los siguientes campos:
-
SourcePath: el valor QueryFilePath que se proporcionó al comando (desde
-qla opción). -
TestFilters: lista de todos los valores testFilter que se aplicaron (desde
--testFilteropciones). -
Pruebas: matriz de objetos de archivo de prueba, donde cada objeto contiene:
- Prueba: nombre de archivo del archivo de prueba.
-
RelativePath: ruta de acceso relativa al directorio de prueba base especificado por
-q. - AbsolutePath: ruta de acceso absoluta completa al archivo de prueba.
Combinación con filtros de prueba
La --listOnly opción respeta todas las --testFilter opciones, lo que le permite obtener una vista previa del efecto de los filtros:
<Path to PQTest.exe>.\PQTest.exe run-compare -e contoso.mez -q .\test --testFilter "Suite1/**/*.pq" --listOnly
Nota:
Todos los filtros de prueba se aplican antes de generar la lista. No se produce ninguna ejecución de prueba real al usar --listOnly.
Administración de resultados intermedios de pruebas
El comando run-compare genera archivos intermedios durante la ejecución de pruebas, incluidos los archivos de salida de prueba reales (.pqout) y los archivos de diagnóstico (.diagnostics). De forma predeterminada, estos archivos se crean en una ubicación temporal con una estructura de subcarpeta basada en fecha y se limpian automáticamente una vez completada la ejecución de la prueba.
Puede controlar este comportamiento mediante dos opciones:
-
--intermediateTestResultsFolder | -itrf: especifica una ruta de acceso de carpeta personalizada para almacenar los resultados intermedios de las pruebas. -
--persistIntermediateTestResults | -pitr: mantiene los resultados intermedios después de que se complete la ejecución de la prueba.
Ejemplo 10: Usar una carpeta intermedia personalizada y conservar los resultados
<Path to PQTest.exe>.\PQTest.exe run-compare -e contoso.mez -q .\test -itrf "C:\TestResults" -pitr
Estructura intermedia de carpetas
Al especificar una carpeta intermedia de resultados de pruebas, PQTest crea una estructura de subcarpeta basada en fechas para organizar los resultados de las pruebas:
<IntermediateTestResultsFolder>\
└── YYYYMMDD_HHmmss_ffffff\
├── Test1.query.pqout
├── Test2.query.pqout
├── Test3.query.odbc.diagnostics
└── ...
Comportamiento de limpieza
El comportamiento de limpieza depende de si especifica una carpeta intermedia y si usa la marca persistente:
| Scenario | Carpeta intermedia especificada | Indicador persistente | Comportamiento |
|---|---|---|---|
| 1 | No | No | Archivos creados en la ubicación temporal. La subcarpeta estructurada según la fecha se elimina después de las pruebas. |
| 2 | Yes | No | Archivos creados en la carpeta especificada, subcarpeta basada en fechas eliminadas después de las pruebas |
| 3 | No | Yes | Archivos creados en la ubicación temporal, subcarpeta basada en fechas eliminadas después de las pruebas |
| 4 | Yes | Yes | Archivos creados en la carpeta especificada, subcarpeta con fecha conservada |
Nota:
Para conservar los resultados intermedios, debe especificar tanto --intermediateTestResultsFolder como --persistIntermediateTestResults. La --persistIntermediateTestResults marca solo sin especificar una carpeta no conserva los resultados. Si la carpeta intermedia especificada no existe, PQTest intenta crearla. Se admiten rutas de acceso relativas y se resuelven en relación con el directorio de trabajo actual.