How are folks running tests against `wasmWasi` whi...

# webassembly

[damian]

How are folks running tests against wasmWasi which depends on WasmImport host functions? In my ideal world, I'd like to be able to run against something like Endive (where I can leverage existing JVM ecosystem libraries to implement those host functions). But as maybe second-best, implement those host functions in some other language to somehow bind in the test environment

[jessewilson]

It isn't ready yet, but Brevity aught to be able to do this soon.

[jessewilson]

We're using Chicory with plans to switch to either Endive, or another faster engine

[jessewilson]

We can currently generate all the types and interfaces for WASI p2 and p3, and bridge calls for most stuff.

[jessewilson]

It's incomplete (async for WASI p3, bridging resources, no built in implementations of either WASI version)

[damian]

I've had my eye on some of your WASM-relating things - looks very promising! And relevant to what I'm currently working on.

At this point though we don't really need WIT, and we need to keep things simple for supporting different runtimes (including those which don't yet support newer WASI stuff), so I'm mostly just working with WasmExport and WasmImport. I will definitely keep an eye on this stuff though.

At the moment, I'm mostly looking for a way to run tests in a pretty vanilla wasmWasi target where I can bind host functions. I suppose I could implement a custom test task to set this up (just run a custom executable that links the wasm executable and runs it with the needed functions) but was hoping there's already some prior art for that.

[CharlieTap]

Chasm supports WASI P1 if that's at all relevant to the host functions you're trying to fill? If you use the Gradle Plugin it will automatically bind the host functions for you, you just need to give it the binary.

Last I checked it's faster than Endive Interp and AOT

github.com/CharlieTap/chasm

[damian]

Neat. I need to bind some other functions so that's not quite enough. But that's alright, I think I figured it out. What I did, for the curious:
• Implement a custom TestEngine with JUnit platform which executes a wasm binary from resources using Endive, and reports results from it (need to parse the ##teamcity[...] events from stdout)
• Create a new compilation and test run for "hosted wasm wasi" test on JVM
• Wire the test compilation output into the resources for this compilation
TL;DR gradle config:

kotlin {
    // ...configure wasmWasi...
    val moduleName = targets
        .named<KotlinWasmWasiTargetDsl>("wasmWasi")
        .flatMap { it.compilations.named("test") }
        .flatMap { it.outputModuleName }
    val outputDir = tasks
        .named<KotlinJsIrLink>("compileTestDevelopmentExecutableKotlinWasmWasi")
        .flatMap { it.destinationDirectory }
    jvm {
        val hostedWasmWasiTest = compilations.create("hostedWasmWasiTest")
        testRuns.create("hostedWasmWasi") {
            setExecutionSourceFrom(hostedWasmWasiTest)
            executionTask.configure {
                useJUnitPlatform {
                    includeEngines("hosted-wasm-wasi") // ID of the "hosted wasm-wasi" test engine, implemented in `:my-hosted-testing`
                }
                systemProperty("hosted.wasm.module-name", moduleName.get()) // allows locating the correct resource by name
                targetName = "wasmWasi"
                testClassesDirs = compilations.getByName("main").output.classesDirs // ensure test task isn't skipped w/ NO-SOURCE
                isScanForTestClasses = false
            }
        }
    }
    sourceSets.named("jvmHostedWasmWasiTest").configure {
        resources.srcDirs(outputDir)
    }
}

dependencies {
    add("jvmHostedWasmWasiTestImplementation", testFixtures(project(":my-hosted-testing"))) // implements the `TestEngine`
}