Condividi tramite

Testare i moduli WASM

Il test dei moduli WASM a più livelli consente di rilevare i problemi in anticipo e di convalidare la logica di elaborazione prima della distribuzione nell'ambiente di produzione. Questo articolo descrive come eseguire unit test dei moduli, esaminare l'output WASM ed eseguire test locali e end-to-end per i grafici del flusso di dati Azure IoT Operations.

Prima di completare i passaggi descritti in questo articolo, configurare l'ambiente di sviluppo locale ed eseguire un'applicazione graph in locale. Per altre informazioni, vedere Creare moduli WASM per i flussi di dati.

Prerequisiti

Completare i prerequisiti elencati in Compilare moduli WASM per i flussi di dati.

Test unitario

Estrarre la logica di base in funzioni semplici che è possibile testare senza WASM:

// In src/lib.rs - extract the conversion logic
pub fn fahrenheit_to_celsius(f: f64) -> f64 {
    (f - 32.0) * 5.0 / 9.0
}

#[cfg(test)]
mod tests {
    use super::*;

    #[test]
    fn test_boiling_point() {
        assert!((fahrenheit_to_celsius(212.0) - 100.0).abs() < 0.001);
    }

    #[test]
    fn test_freezing_point() {
        assert!((fahrenheit_to_celsius(32.0) - 0.0).abs() < 0.001);
    }

    #[test]
    fn test_body_temperature() {
        assert!((fahrenheit_to_celsius(98.6) - 37.0).abs() < 0.001);
    }
}

cargo test  # Runs tests without WASM target

Esaminare l'output WASM

Verificare che il modulo esporta le interfacce previste prima di eseguire il push in un registro:

wasm-tools component wit your-module.wasm

Vengono visualizzate le interfacce WIT implementate dal modulo. Verificare che venga visualizzata l'esportazione prevista map, filter o branch.

Test locali con la CLI aio-dataflow

L'interfaccia della aio-dataflow riga di comando consente di testare i moduli WASM localmente contro una definizione del grafo senza distribuirli in un cluster. L'interfaccia della riga di comando usa contenitori Docker per simulare il runtime del flusso di dati.

Per creare un test case, creare una directory con la struttura seguente:

my-test/
  my-test.test.yaml     # Test descriptor
  input/                 # Input data files
    temperature.json
  expected/              # Expected output
    expected.json

Definire il test nel .test.yaml file:

name: "Temperature F to C conversion"
graph: "../graph-simple.yaml"
input: "./input"
expected: "./expected/expected.json"
timeout: 90000
select: ["payload"]

Il graph campo punta alla definizione del grafo, input contiene i dati di test e expected ha l'output da confrontare. Il select campo specifica i campi dell'output da confrontare.

Eseguire il test:

aio-dataflow run start
aio-dataflow build --app .
aio-dataflow test --app . my-test
aio-dataflow run stop

Per un set completo di esempi di test, vedere la directory test-runner/tests nel repository degli esempi.

Test end-to-end su un cluster

Per i test di integrazione, distribuire il modulo in un cluster di sviluppo e usare MQTT per inviare dati di test:

  1. Spingere il modulo in un registro di test.
  2. Distribuire un DataflowGraph che punta o al registro di test.
  3. Iscriviti al topic di output: mosquitto_sub -h localhost -t "output/topic" -v
  4. Pubblicare messaggi di test: mosquitto_pub -h localhost -t "input/topic" -m '{"temperature": {"value": 72}}'
  5. Verificare che l'output corrisponda alle aspettative.
  6. Controllare la presenza di errori nei log dei pod: kubectl logs -l app=aio-dataflow -n azure-iot-operations --tail=50

Per altre informazioni, vedere Distribuire moduli e definizioni di grafo e Configurare gli endpoint del Registro di sistema.

Contenuti correlati

  • Last updated on