WASM-modules testen

Door uw WASM-modules op meerdere niveaus te testen, kunt u problemen vroegtijdig ondervangen en uw verwerkingslogica valideren voordat u implementeert in productie. In dit artikel wordt beschreven hoe u uw modules test, WASM-uitvoer inspecteert en lokale en end-to-end tests uitvoert voor Azure IoT-bewerkingen gegevensstroomgrafieken.

Voordat u de stappen in dit artikel uitvoert, moet u uw lokale ontwikkelomgeving instellen en lokaal een grafiektoepassing bouwen en uitvoeren. Zie voor meer informatie Build WASM-modules voor gegevensstromen.

Vereiste voorwaarden

Voltooi de vereisten die worden vermeld in build-WASM-modules voor gegevensstromen.

Het testen van modules

Pak uw kernlogica uit in gewone functies die u kunt testen zonder 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

WASM-uitvoer controleren

Controleer of de module de verwachte interfaces exporteert voordat u naar een register pusht:

wasm-tools component wit your-module.wasm

Hier ziet u de WIT-interfaces die uw module implementeert. Controleer of u de verwachte map, filterof branch export ziet.

Lokaal testen met de dataflow-dev CLI

Met de dataflow-dev CLI kunt u uw WASM-modules lokaal testen op basis van een grafiekdefinitie zonder te implementeren in een cluster. De CLI maakt gebruik van Docker-containers om de gegevensstroomruntime te simuleren.

Als u een testcase wilt maken, maakt u een map met de volgende structuur:

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

Definieer de test in het .test.yaml bestand:

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

Het graph veld verwijst naar de grafiekdefinitie, input bevat de testgegevens en expected bevat de uitvoer om mee te vergelijken. Het select veld geeft aan welke velden van de uitvoer moeten worden vergeleken.

Voer de test uit:

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

Voor een volledige set testvoorbeelden raadpleegt u de map tests in de opslagplaats met voorbeelden.

End-to-end testen op een cluster

Implementeer uw module voor integratietests naar een ontwikkelcluster en gebruik MQTT om testgegevens te verzenden:

  1. Push de module naar een testregister.
  2. Implementeer een DataflowGraph die verwijst naar het testregister.
  3. Abonneren op het uitvoeronderwerp: mosquitto_sub -h localhost -t "output/topic" -v
  4. Testberichten publiceren: mosquitto_pub -h localhost -t "input/topic" -m '{"temperature": {"value": 72}}'
  5. Controleer of de uitvoer overeenkomt met de verwachtingen.
  6. Controleer podlogboeken op fouten: kubectl logs -l app=dataflow-dev -n azure-iot-operations --tail=50

Zie Modules en grafiekdefinities implementeren en registereindpunten configureren voor meer informatie.

Verwante inhoud

  • Last updated on