Best practice per i test

Lo sviluppo di un'azione per la piattaforma Actions on Google spesso comporta l'implementazione di Dialogflow per la sua comprensione del linguaggio naturale (NLU) e del fulfillment Dialogflow, che gestisce la logica dell'Azione. L'esecuzione di test nel codebase aiuta a garantire che l'Azione venga eseguita come previsto in produzione.

Quando implementi test delle unità, di integrazione o end-to-end per l'azione, è consigliabile considerare l'agente e il fulfillment Dialogflow come componenti separati.

Un diagramma di flusso passa dalla query di un utente ad Actions on Google, Dialogflow e un webhook di fulfillment, per poi tornare all'utente.

Figura 1. Diagramma di flusso che descrive i sistemi da considerare per i test

Test di un agente Dialogflow

L'agente e il fulfillment Dialogflow vengono testati come componenti separati. Le seguenti sottosezioni descrivono come concettualizzare e testare l'agente Dialogflow per l'azione.

Dialogflow come sistema di query-in e intent-out

L'agente Dialogflow è responsabile di accettare la query di un utente, associarla a un intent ed estrarre tutte le entità predefinite dalla query. L'agente interagisce con il fulfillment passando un messaggio contenente l'intent corrispondente, i relativi parametri e i metadati di Actions on Google.

In qualità di sviluppatore, puoi controllare la configurazione dell'agente Dialogflow, ad esempio la struttura di intent ed entità. I metadati di Actions on Google provengono da Actions on Google e si presume che contengano i dati corretti per i test.

Durante i test, concentrati su come rendere l'agente in grado di estrarre correttamente i parametri di intent e associare le query agli intent. Questo approccio fornisce una metrica quantificabile per valutare le prestazioni dell'agente. Puoi calcolare questa metrica preparando e utilizzando singoli scenari di test o un set di convalida.

Un agente Dialogflow può essere rappresentato con una query di testo come input e un
intent più parametri di intent estratti come output.

Figura 2. Rappresentazione di Dialogflow come sistema di query in entrata e intent-out

Test delle unità

Per l'agente Dialogflow, puoi scrivere test in cui ogni caso prevede una query di testo come input e produce metadati di intent come output. Questi metadati devono contenere almeno il nome dell'intent con corrispondenza e un elenco di parametri corrispondenti.

L'endpoint detectIntent dell'API Dialogflow utilizza la query di testo come input e produce un output strutturato contenente il nome dell'intent risolto e i parametri estratti. Questo output è utile per valutare le prestazioni di intent-matching dell'agente. Per un riferimento completo ad altri campi utili, consulta la documentazione di riferimento di QueryResult.

Un test di esempio ha il seguente aspetto:

it('choose_fact', async function() {
  // The `dialogflow` variable is an abstraction around the API that creates
  // and sends payloads to Dialogflow.
  const resJson = await dialogflow.detectIntent(
    'Tell me about the history of Google');
  expect(resJson.queryResult).to.include.deep.keys('parameters');
  // Check that Dialogflow extracted required entities from the query.
  expect(resJson.queryResult.parameters).to.deep.equal({
    'category': 'history',
    // Put any other parameters you wish were extracted
  });
  expect(resJson.queryResult.intent.displayName).to.equal('choose_fact');
});

Questo snippet utilizza Mocha e Chai. Consulta l'esempio funzionante completo del test delle unità Dialogflow scritto in Node.js nella sezione Facts About Google.

I file di test possono essere eseguiti in parallelo perché l'API Dialogflow accetta un sessionId come argomento. Di conseguenza, puoi avere una sandbox separata per ogni conversazione quando utilizzi un singolo client API Dialogflow.

Poiché stai effettuando richieste tramite l'API Dialogflow, potrebbe esserti addebitato un costo se viene raggiunta la quota di chiamate senza costi. Vedi Quote e limiti per ulteriori informazioni.

Test di integrazione

L'endpoint detectIntent dell'API Dialogflow attiva anche il fulfillment di terze parti. Pertanto, è possibile scrivere scenari di test che coprono l'integrazione tra l'agente Dialogflow e il fulfillment Dialogflow.

La differenza principale tra la scrittura dell'integrazione e dei test delle unità per Dialogflow è che, nel test di integrazione, puoi dichiarare le risposte provenienti dal webhook, nonché l'estrazione delle entità e dell'intent Dialogflow.

Vedi l'esempio funzionante completo di un test di integrazione scritto in Node.js nel repository Facts About Google.

Test di un webhook di fulfillment Dialogflow

L'agente Dialogflow e il fulfillment Dialogflow vengono testati come componenti separati. Le seguenti sottosezioni descrivono come concettualizzare e testare il fulfillment per l'Azione.

Evasione degli ordini come sistema JSON-in e JSON-out

Il codice di fulfillment Dialogflow prevede richieste e produce risposte in formato JSON. Puoi quindi testare il codice di fulfillment pensando a un sistema JSON-in e JSON-out. La richiesta contiene metadati sia di Dialogflow che di Actions on Google, quindi ha tutto ciò che serve per attivare un determinato gestore di intent nel fulfillment.

Per testare l'attivazione di un gestore di intent, devi inviare una richiesta JSON (input) all'Azione. Questa richiesta viene passata al fulfillment, che è accessibile su internet. Il fulfillment genera quindi una risposta JSON (output), che può essere valutata per la convalida.

Un fulfillment può essere rappresentato con un input di richiesta JSON e un output della risposta JSON webhook.

Figura 3. Rappresentazione di un fulfillment come sistema JSON-in e JSON-out

Test delle unità

Pensa al codice webhook di fulfillment come a un sistema che accetta un input JSON e produce un output JSON. Il processo di test di un'azione viene quindi semplificato per fornire una richiesta al fulfillment e controllare il JSON di output risultante.

Ciò ti dà la libertà di ospitare il fulfillment localmente e di inviare le richieste HTTP localmente per i test. Se stai utilizzando la libreria client Actions on Google Node.js, puoi anche inviare richieste JSON direttamente al livello middleware della libreria client.

Se testi il codice webhook con input JSON e ricevi gli output JSON previsti, puoi affermare con ragionevole sicurezza che le parti che controlli funzionano correttamente. Puoi presumere che Dialogflow e Actions on Google funzionino correttamente perché generano i payload JSON corretti. Questo isolamento fornisce un modello di programmazione semplificato per la scrittura di test.

Di seguito viene riportata una descrizione generale della procedura di test:

  1. Utilizza il simulatore nella console di Actions per ottenere le richieste JSON per ogni passaggio in un caso d'uso. Salvali come file JSON. In alternativa, puoi creare queste richieste autonomamente utilizzando le informazioni contenute nella documentazione di riferimento per i webhook.
  2. Scrivi i test per richiamare il webhook con questi payload.
  3. Per ogni test, assicurati che il JSON della risposta contenga gli elementi previsti.

Inoltre, questo modello consente di testare il fulfillment di Dialogflow in un'impostazione di integrazione continua, poiché l'endpoint di fulfillment può essere eseguito localmente e l'API Dialogflow ha un concetto integrato di sessioni.

Ecco un esempio di test:

it('yes-history', function() {
  expect(jsonRes.payload).to.have.deep.keys('google');
  expect(jsonRes.payload.google.expectUserResponse).to.be.true;
  expect(jsonRes.payload.google.richResponse.items).to.have.lengthOf(3);
  expect(jsonRes.payload.google.richResponse.suggestions).to.have
    .deep.members([
      {'title': 'Sure'}, {'title': 'No thanks'},
    ]);
});

Lo snippet riportato sopra utilizza Mocha e Chai. Consulta l'esempio di lavoro completo scritto in Node.js nel repository Facts About Google.

Progettazione del fulfillment testabile delle unità

Il codice webhook contiene spesso una logica di business personalizzata su cui l'applicazione fa affidamento per soddisfare le sue esigenze. Inoltre, il codice webhook può contenere gestori di intent.

Per migliorare la granularità dei test delle unità per il codice di fulfillment, è buona norma organizzare il codice in modo che la logica di business sia disaccoppiata dalle routine di gestione degli intent. Ciò significa avere i gestori di intent e la logica di business in moduli separati, in modo che ogni parte possa essere testata in modo indipendente.

Per un esempio, fai riferimento alla nostra azione di esempio shiritori su GitHub. In questo campione, functions/index.js e functions/shiritori/*.js contengono separatamente i gestori di intent e la logica di business, consentendo di creare suite di test più affidabili.

Test di integrazione

Per scrivere scenari di test che coprono l'integrazione tra Dialogflow e il codice webhook di fulfillment, leggi la sezione relativa ai test dell'integrazione per Dialogflow sopra.

Test di carico

Prima di eseguire il deployment dell'azione in produzione, ti consigliamo anche di eseguire il test di carico del fulfillment webhook per individuare i problemi di prestazioni che causano il degrado o l'interruzione del servizio di fulfillment.

Di seguito sono riportati alcuni esempi di problemi di prestazioni che potresti rilevare nei test di carico:

  • Capacità di calcolo e memoria limitate
  • Limitazioni di quota dei tuoi provider
  • Lettura e scrittura dei dati lente
  • Problemi di contemporaneità nel codice

Gli scenari dei test di carico dipendono dal modello di utilizzo previsto o storico dell'Azione, ma gli scenari tipici da testare sono aumenti improvvisi del carico (picco) e carichi sostenuti (soak).

Identificare gli scenari in cui il webhook viene chiamato ed esegue operazioni che richiedono molte risorse. Le operazioni tipiche che richiedono molte risorse includono l'esecuzione di query su un database, la chiamata di un'altra API, l'esecuzione di operazioni di calcolo e che richiedono molta memoria, come il rendering di un file audio.

Per questi scenari, puoi acquisire le richieste inviate dai server Actions on Google al webhook dai log dei webhook o dai log di Stackdriver. Puoi acquisire le richieste anche dal simulatore della console di Actions.

Una volta ricevute le richieste, puoi utilizzare uno strumento di test di carico per scoprire come risponde il webhook in diversi scenari di test di carico. Le seguenti sottosezioni forniscono alcuni esempi di test di picco e test di soak mediante ApacheBench.

Test dei picchi

Il test dei picchi richiede di inviare un numero costante di richieste al webhook per un po' di tempo e di aumentare improvvisamente il carico. Ad esempio, puoi configurare un test che invia un carico di 10 query al secondo (QPS) con alcuni picchi di 60 QPS.

Puoi eseguire il seguente comando ApacheBench per inviare 60 richieste in parallelo al tuo webhook:

ab -n 60 -c 60 -p ActionRequest.json -T 'application/json' https://example.com/webhookFunctionName

Supponiamo che il file ActionRequest.json contenga il payload della richiesta acquisito inviato al tuo webhook.

Test Soak

Il test Soak richiede di inviare un numero costante di richieste al webhook e di osservare la risposta. Ad esempio, puoi configurare un test che invia un carico costante di 10-20 QPS per diversi minuti per vedere se i tempi di risposta aumentano.

Puoi eseguire il seguente comando ApacheBench per inviare 1200 richieste, con 10 richieste in parallelo ogni secondo:

ab -t 120 -n 1200 -p ActionRequest.json -T 'application/json' https://example.com/webhookFunctionName

Supponiamo che il file ActionRequest.json contenga il payload della richiesta acquisito inviato al tuo webhook.

Analisi dei risultati del test di carico

Dopo aver eseguito i test di carico, analizza i risultati per conoscere i tempi di risposta del webhook. Gli indicatori dei problemi nell'implementazione del webhook sono generalmente tendenze come un tempo di risposta medio che aumenta a ogni esecuzione di test o un tempo di risposta nei casi peggiori non accettabile per l'Azione.

Test end-to-end

Per eseguire test end-to-end prima dell'invio dell'Azione per l'approvazione, viene utilizzato il simulatore della console Actions. Puoi trovare la procedura per i test end-to-end tramite il simulatore della console di Actions nella documentazione del Simulatore di Actions. L'esecuzione di questi test consente di eliminare potenziali incertezze dal componente dell'infrastruttura Actions on Google.