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.
Se aplica a: Azure Logic Apps (estándar)
Las pruebas unitarias son una práctica esencial que mantiene la aplicación o solución confiable y precisa durante todo el ciclo de vida de desarrollo de software. Las pruebas unitarias le ayudan a validar de forma eficaz y sistemática los componentes clave de la solución.
En el caso de los flujos de trabajo de aplicaciones lógicas estándar, puede crear pruebas unitarias mediante Visual Studio Code y la extensión Azure Logic Apps (Estándar). Esta funcionalidad le permite usar definiciones de flujo de trabajo para crear pruebas unitarias y adaptarlas a escenarios admitidos por la solución de aplicación lógica, todo ello sin necesidad de conexiones a ningún servicio, sistema o API externos. Este enfoque le permite probar los flujos de trabajo sin tener que interactuar con servicios externos, sistemas o API y proporciona las siguientes ventajas:
Mejore la calidad del flujo de trabajo mediante la identificación y la resolución de posibles problemas antes de implementar en otros entornos.
Optimice la integración de pruebas unitarias con el proceso de desarrollo, a la vez que garantiza un comportamiento de flujo de trabajo coherente y preciso.
En esta guía se muestra cómo crear una definición de prueba unitaria a partir de un flujo de trabajo. Esta definición simula las llamadas externas de cada operación de flujo de trabajo sin cambiar la lógica del flujo de trabajo. Al crear una prueba unitaria para un flujo de trabajo, obtendrá un proyecto de prueba unitaria que incluya las siguientes carpetas:
Carpeta que contiene clases fuertemente tipadas para cada operación simulable en tu flujo de trabajo.
Carpeta para cada definición de prueba unitaria. Esta carpeta incluye un archivo de C# que contiene una clase y métodos de ejemplo. Use esta clase y métodos para configurar sus propias aserciones, confirme que el flujo de trabajo se comporta según lo previsto y asegúrese de que el flujo de trabajo se comporta de forma confiable y predecible en el ecosistema de Azure más grande.
Prerrequisitos
Una cuenta y una suscripción de Azure. Si no tiene una suscripción, regístrese para obtener una cuenta gratuita de Azure.
Un proyecto de aplicación lógica estándar en Visual Studio Code que contiene al menos una definición de flujo de trabajo que se va a usar para crear una prueba unitaria.
Para obtener más información sobre la configuración y la creación de proyectos de Visual Studio Code, consulte Creación de flujos de trabajo de aplicaciones lógicas estándar con Visual Studio Code.
Limitaciones y problemas conocidos
Actualmente, esta versión solo admite C# para crear pruebas unitarias.
Esta versión no admite acciones no simuladas. Asegúrese de que todas las acciones de la ruta de acceso de ejecución del flujo de trabajo se simulan.
Esta versión no admite los siguientes tipos de acción:
- Acciones de la cuenta de integración
- Acciones de codificación y descodificación de EDI
Revisión de los conceptos básicos
En la lista siguiente se incluyen conceptos básicos pero importantes sobre las pruebas unitarias para flujos de trabajo estándar:
Prueba unitaria de aplicación lógica
Ejecución controlada del flujo de trabajo que inserta objetos ficticios. Estos objetos representan el desencadenador de flujo de trabajo o las acciones que dependen de servicios o sistemas externos.
Acción simulable
Acción de flujo de trabajo que depende de un servicio o sistema externo. Puede convertir estas acciones en acciones simuladas para la creación y ejecución de pruebas unitarias.
Creación de una prueba unitaria a partir de una definición de flujo de trabajo
En Visual Studio Code, abra el proyecto de aplicación lógica estándar.
En el proyecto, expanda la carpeta de definición de flujo de trabajo.
En el menú contextual del archivo workflow.json , seleccione Abrir diseñador.
En la barra de herramientas del diseñador, seleccione Crear prueba unitaria.
Proporcione un nombre que se usará para la prueba unitaria, la clase de prueba unitaria y el archivo de C#.
Ahora aparece una nueva carpeta denominada Tests en el área de trabajo del proyecto. Esta carpeta tiene la siguiente estructura:
Archivo o carpeta Descripción Tests
|| <logic-app-name
>En la carpeta Tests
, una carpeta <logic-app-name
> aparece al agregar pruebas unitarias a un proyecto de Logic App.Tests
|| <logic-app-name
>
||| <workflow-name
>En la carpeta < logic-app-name
>, aparece una carpeta <workflow-name
> al agregar pruebas unitarias para un flujo de trabajo.Tests
|| <logic-app-name
>
||| <workflow-name
>
||||MockOutputs
<operation-name-outputs
>||||| .cs
En la carpeta < workflow-name
>, la carpetaMockOutputs
contiene un archivo de C# (.cs) con clases fuertemente tipadas para cada operación del conector en el flujo de trabajo. Cada .cs nombre de archivo usa el siguiente formato:
<operation-name
>[Trigger\|Action
]Output.cs
Si una operación de conector tiene contratos dinámicos, aparece una clase para cada tipo dinámico. Un tipo dinámico hace referencia a un parámetro de operación que tiene entradas y salidas diferentes en función del valor proporcionado para ese parámetro. Puede usar estas clases para ampliar las pruebas unitarias y crear nuevos simulacros desde cero.Tests
|| <logic-app-name
>
||| <workflow-name
>
|||| <unit-test-name
>
||||| <unit-test-name
>.cs
En la < workflow-name
> carpeta , la <unit-test-name
> carpeta contiene un <unit-test-name
>.cs
archivo. Use este archivo, que contiene una clase y métodos de C# de ejemplo, para ejecutar y declarar los resultados. Puede editar este archivo para que coincida con sus escenarios de prueba específicos.
Revise el archivo de prueba unitaria *.cs
Esta clase de prueba unitaria proporciona un marco para probar flujos de trabajo de aplicaciones lógicas estándar simulando desencadenadores y acciones. Esta clase le permite probar flujos de trabajo sin llamar realmente a servicios externos o API.
Estructura de clase de prueba
Una clase de prueba unitaria típica usa la estructura siguiente:
[TestClass]
public class <unit-test-name>
{
public TestExecutor TestExecutor;
[TestInitialize]
public void Setup()
{
this.TestExecutor = new TestExecutor("<workflow-name>/testSettings.config");
}
// Add test methods here.
// Add helper methods here.
}
Método Setup()
Este método crea una instancia de la TestExecutor
clase mediante la ruta de acceso al archivo de configuración de configuración de la prueba. El método se ejecuta antes de cada ejecución de prueba y crea una nueva instancia de TestExecutor
.
[TestInitialize]
public void Setup()
{
this.TestExecutor = new TestExecutor("<workflow-name>/testSettings.config");
}
Métodos de prueba de ejemplo
En la sección siguiente se describen los métodos de prueba de ejemplo que puede usar en la clase de prueba unitaria.
Prueba estática de datos ficticios
El método siguiente muestra cómo usar datos ficticios estáticos para probar el flujo de trabajo. En este método, puede completar las siguientes tareas:
- Establezca los valores de propiedad en las acciones simuladas.
- Ejecute el flujo de trabajo con los datos ficticios configurados.
- Confirme que la ejecución se realizó correctamente.
[TestMethod]
public async Task <workflow-name>_<unit-test-name>_ExecuteWorkflow_SUCCESS_Sample1()
{
// PREPARE mock: Generate mock trigger data.
var triggerMockOutput = new WhenMessagesAreAvailableInAQueuePeeklockTriggerOutput();
// Sample that shows how to set the properties for triggerMockOutput
// triggerMockOutput.Body.Id = "SampleId";
var triggerMock = new WhenMessagesAreAvailableInAQueuePeeklockTriggerMock(outputs: triggerMockOutput);
// Generate mock action data.
var actionMockOutput = new CallExternalAPIActionOutput();
// Sample that shows how to set the properties for actionMockOutput
// actionMockOutput.Body.Name = "SampleResource";
// actionMockOutput.Body.Id = "SampleId";
var actionMock = new CallExternalAPIActionMock(name: "Call_External_API", outputs: actionMockOutput);
// ACT: Create the UnitTestExecutor instance. Run the workflow with mock data.
var testMock = new TestMockDefinition(
triggerMock: triggerMock,
actionMocks: new Dictionary<string, ActionMock>()
{
{actionMock.Name, actionMock}
});
var testRun = await this.TestExecutor
.Create()
.RunWorkflowAsync(testMock: testMock).ConfigureAwait(continueOnCapturedContext: false);
// ASSERT: Confirm successful workflow execution and that the status is 'Succeeded'.
Assert.IsNotNull(value: testRun);
Assert.AreEqual(expected: TestWorkflowStatus.Succeeded, actual: te
stRun.Status);
}
Prueba dinámica de datos ficticios
El método siguiente muestra cómo usar datos ficticios dinámicos con métodos de devolución de llamada. Este enfoque proporciona dos opciones que generan dinámicamente datos ficticios:
- Defina un método de devolución de llamada independiente.
- Use una función lambda insertada.
Ambos enfoques permiten crear respuestas dinámicas basadas en el contexto de ejecución de pruebas unitarias.
[TestMethod]
public async Task <workflow-name>_<unit-test-name>_ExecuteWorkflow_SUCCESS_Sample2()
{
// PREPARE: Generate mock trigger data.
var triggerMockOutput = new WhenMessagesAreAvailableInAQueuePeeklockTriggerOutput();
// Sample that shows how to set triggerMockOutput properties.
// triggerMockOutput.Body.Flag = true;
var triggerMock = new WhenMessagesAreAvailableInAQueuePeeklockTriggerMock(outputs: triggerMockOutput);
// PREPARE: Generate mock action data.
// OPTION 1: Define a callback class.
var actionMock = new CallExternalAPIActionMock(name: "Call_External_API", onGetActionMock: CallExternalAPIActionMockOutputCallback);
// OPTION 2: Define inline with a lambda function.
/*var actionMock = new CallExternalAPIActionMock(name: "Call_External_API", onGetActionMock: (testExecutionContext) =>
{
return new CallExternalAPIActionMock(
status: TestWorkflowStatus.Succeeded,
outputs: new CallExternalAPIActionOutput {
// If this account contains a JObject Body,
// set the properties you want here:
// Body = "something".ToJObject()
}
);
});*/
// ACT: Create the UnitTestExecutor instance. Run the workflow with mock data.
var testMock = new TestMockDefinition(
triggerMock: triggerMock,
actionMocks: new Dictionary<string, ActionMock>()
{
{actionMock.Name, actionMock}
});
var testRun = await this.TestExecutor
.Create()
.RunWorkflowAsync(testMock: testMock).ConfigureAwait(continueOnCapturedContext: false);
// ASSERT: Confirm successful workflow execution and that the status is 'Succeeded'.
Assert.IsNotNull(value: testRun);
Assert.AreEqual(expected: TestWorkflowStatus.Succeeded, actual: testRun.Status);
}
Métodos auxiliares
En la sección siguiente se describen los métodos de prueba usados por los métodos de prueba de ejemplo. Los métodos auxiliares aparecen en los métodos de prueba de la definición de clase.
Método de devolución de llamada
El método siguiente genera dinámicamente datos ficticios. El nombre del método varía en función del nombre de la acción simulada en los métodos de prueba para los datos ficticios estáticos o dinámicos. Puede editar este método para devolver diferentes respuestas ficticias en función de los requisitos del escenario de prueba o usarla como plantilla para crear sus propios métodos de devolución de llamada dinámicos.
public CallExternalAPIActionMock CallExternalAPIActionMockOutputCallback(TestExecutionContext context)
{
// Sample mock data: Dynamically change the mocked data for 'actionName'.
return new CallExternalAPIActionMock(
status: TestWorkflowStatus.Succeeded,
outputs: new CallExternalAPIActionOutput {
// If this account contains a JObject Body,
// set the properties you want here:
// Body = "something".ToJObject()
}
);
}