Creare unit test dalle definizioni del flusso di lavoro Standard in App per la logica di Azure con Visual Studio Code

Si applica a: Azure Logic Apps (Standard)

Gli unit test sono una pratica essenziale che consente di mantenere l'app o la soluzione affidabile e accurata nel ciclo di vita dello sviluppo software. Gli unit test consentono di convalidare in modo efficiente e sistematico i componenti chiave nella soluzione.

Per i flussi di lavoro delle app per la logica Standard, è possibile creare unit test usando Visual Studio Code e l'estensione App per la logica di Azure (Standard). Questa funzionalità consente di usare le definizioni del flusso di lavoro per creare unit test e personalizzarle in base agli scenari supportati dalla soluzione dell'app per la logica, senza che siano necessarie connessioni a servizi, sistemi o API esterni. Questo approccio consente di testare i flussi di lavoro senza dover interagire con servizi, sistemi o API esterni e offre i vantaggi seguenti:

• Migliorare la qualità del flusso di lavoro identificando e risolvendo potenziali problemi prima di eseguire la distribuzione in altri ambienti.

• Semplificare l'integrazione degli unit test con il processo di sviluppo, garantendo al tempo stesso un comportamento coerente e accurato del flusso di lavoro.

Questa guida illustra come creare una definizione di unit test da un flusso di lavoro. Questa definizione simula le chiamate esterne da ogni operazione del flusso di lavoro senza modificare la logica del flusso di lavoro. Quando si crea uno unit test per un flusso di lavoro, si ottiene un progetto di unit test che include le cartelle seguenti:

• Cartella che contiene classi fortemente tipate per ogni operazione simulabile nel flusso di lavoro.

• Una cartella per ogni definizione di test unitario. Questa cartella include un file C# che contiene una classe e metodi di esempio. Questa classe e i metodi vengono usati per configurare le proprie asserzioni, verificare che il flusso di lavoro si comporti come previsto e assicurarsi che il flusso di lavoro si comporti in modo affidabile e prevedibile nell'ecosistema di Azure più ampio.

Prerequisiti

• Account e sottoscrizione di Azure. Se non si ha una sottoscrizione, è possibile iscriversi per creare un account Azure gratuito.

• Un progetto di app per la logica Standard in Visual Studio Code che contiene almeno una definizione del flusso di lavoro da usare per la creazione di uno unit test.

  Per altre informazioni sull'installazione e la creazione di progetti di Visual Studio Code, vedere Creare flussi di lavoro di app per la logica standard con Visual Studio Code.

Limitazioni e problemi noti

• Questa versione supporta attualmente solo C# per la creazione di unit test.

• Questa versione non supporta azioni non simulate. Verificare che tutte le azioni nel percorso di esecuzione del flusso di lavoro siano simulate.

• Questa versione non supporta i tipi di azione seguenti:

  • Azioni dell'account di integrazione
  • Azioni di codifica e decodifica EDI

Esaminare i concetti di base

L'elenco seguente include concetti di base ma importanti sugli unit test per i flussi di lavoro Standard:

• Test unitario dell'app logica

  Esecuzione controllata del flusso di lavoro che inserisce oggetti fittizi. Questi oggetti rappresentano il trigger o le azioni del flusso di lavoro che dipendono da servizi o sistemi esterni.

• Azione fittizia

  Azione del flusso di lavoro che dipende da un servizio o un sistema esterno. È possibile convertire queste azioni in azioni fittizie per la creazione e l'esecuzione di unit test.

Creare uno unit test da una definizione del flusso di lavoro

1. In Visual Studio Code aprire il progetto di app per la logica Standard.

2. Nel progetto espandere la cartella di definizione del flusso di lavoro.

3. Dal menu di scelta rapida per il file workflow.json selezionare Apri finestra di progettazione.

4. Sulla barra degli strumenti della finestra di progettazione selezionare Crea unit test.

   

5. Specificare un nome da usare per lo unit test, la classe unit test e il file C#.

   Nell'area di lavoro del progetto viene ora visualizzata una nuova cartella denominata Tests . Questa cartella ha la struttura seguente:

   

   File o cartella	Descrizione
   Tests || <logic-app-name>	Quando si aggiungono unit test a un progetto di logica di app, nella cartella Tests appare una cartella <logic-app-name>.
   Tests || <logic-app-name> ||| <workflow-name>	Nella cartella <logic-app-name> appare una cartella <workflow-name> quando vengono aggiunti degli unit test per un flusso di lavoro.
   Tests || <logic-app-name> ||| <workflow-name> |||| MockOutputs < operation-name-outputs >|||||.cs	Nella cartella <workflow-name>, la cartella MockOutputs contiene un file C# (.cs) con classi fortemente tipizzate per ciascuna operazione del connettore nel flusso di lavoro. Ogni .cs nome file usa il formato seguente: < operation-name >[Trigger\|Action]Output.cs Se un'operazione del connettore ha contratti dinamici, viene visualizzata una classe per ogni tipo dinamico. Un tipo dinamico fa riferimento a un parametro dell'operazione con input e output diversi in base al valore fornito per tale parametro. È possibile usare queste classi per estendere gli unit test e creare nuove simulazioni da zero.
   Tests || <logic-app-name> ||| <workflow-name> |||| <unit-test-name> ||||| <unit-test-name>.cs	Nella cartella <workflow-name>, la cartella <unit-test-name> contiene un file <unit-test-name>.cs. Usare questo file, che contiene una classe e metodi C# di esempio, per eseguire ed asserire i risultati. È possibile modificare questo file in modo che corrisponda agli scenari di test specifici.

Esaminare il file di unit test *.cs

Questa classe di test unitario fornisce un framework per testare i flussi di lavoro dell'applicazione logica Standard mediante la simulazione di trigger e azioni. Questa classe consente di testare i flussi di lavoro senza chiamare effettivamente servizi esterni o API.

Struttura della classe di test

Una tipica classe di unit test usa la struttura seguente:

[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.
}

Metodo Setup()

Questo metodo crea un'istanza della TestExecutor classe usando il percorso del file di configurazione delle impostazioni di test. Il metodo viene eseguito prima di ogni esecuzione di test e crea una nuova istanza di TestExecutor.

[TestInitialize]
public void Setup()
{
    this.TestExecutor = new TestExecutor("<workflow-name>/testSettings.config");
}

Metodi di test di esempio

La sezione seguente descrive i metodi di test di esempio che è possibile usare nella classe di unit test.

Test di dati fittizi statici

Il metodo seguente illustra come usare dati fittizi statici per testare il flusso di lavoro. In questo metodo è possibile completare le attività seguenti:

• Imposta i valori delle proprietà sulle azioni simulate.
• Eseguire il flusso di lavoro con i dati fittizi configurati.
• Verificare che l'esecuzione sia riuscita.

[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);
}

Test di dati fittizi dinamici

Il metodo seguente illustra come usare dati fittizi dinamici con metodi di callback. Questo approccio offre due opzioni che generano dinamicamente dati fittizi:

• Definire un metodo di callback separato.
• Usare una funzione lambda inline.

Entrambi gli approcci consentono di creare risposte dinamiche in base al contesto di esecuzione degli unit test.

[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);
}

Metodi di supporto

Nella sezione seguente vengono descritti i metodi usati dai metodi di test di esempio. I metodi helper appaiono sotto i metodi di test nella definizione della classe.

Metodo di callback

Il metodo seguente genera dinamicamente dati fittizi. Il nome del metodo varia in base al nome dell'azione fittizia nei metodi di test per i dati fittizi statici o dinamici. È possibile modificare questo metodo per restituire risposte fittizie diverse in base ai requisiti dello scenario di test o usarlo come modello per creare metodi di callback dinamici personalizzati.

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()

        }
    );
}

Contenuti correlati

• Creare unit test dal flusso di lavoro Standard in App per la logica di Azure con Visual Studio Code