#WASM Testing

25 messages · Page 1 of 1 (latest)

crisp scarab
#

Hoping to start a discussion around how to approach testing contracts within the WASM VM. (To the discussion board owners could a test tag be added?)

It's unclear how realistic testing with Rust is as compared to what contracts will experience when running in production. For example, I currently can perform floating point math and dynamic memory allocation within unit tests. To me, it feels like an integration level testing option that uses the WASM VM would be beneficial.

The soroban-cli and js-soroban-sdk feel more appropriate for adhoc testing, rather than an actual integration suite.

Curious if there is something I am missing or if others have thoughts!

normal lantern
#

I'm pretty sure that's something that has been discussed, but I can't find the respective issue... there is https://github.com/stellar/rs-soroban-sdk/issues/528 that touches this topic, but from a bit different angle. IIRC the contract imports already happen in the VM, so adding some switch to execute all the contracts in the VM. I suspect that's even possible to do right now, but requires some manual work to set everything up

#

something like that would allow to run your unit tests using the VM. I think to make the integration tests the capability to test against the ledger snapshot would be needed and that's also something in plans

plain brook
crisp scarab
#

Yep, the ability to execute tests against the VM would be perfect. Even better if there is someway to include a ledger snapshot. As long as this is in the plans, that works for me.

To note, I think there is some value in being able to have both of these types of tests to be run separately.

normal lantern
#

yeah, sure. Ideally I'd like to have a feature that would either run all the contracts natively (for the sake of debugging subcontract calls) or in VM (to make sure everything works as expected)

ruby patrol
#

You can manually run your contract in a VM by building the .wasm file first, and then importing that .wasm file either with contractimport! or include_bytes!, and then calling env.register_contract_wasm instead of env.register_contract.

#

Note that unit tests do let you do things like alloc, because Rust tests run with std enabled because the Rust test harness uses it. So you can always do more in a Rust test than you can in a wasm build. We're striving to make the execution of a contract function identical in Rust tests when it comes to how the host behaves and how SDK functions/types behave.

crisp scarab
# ruby patrol Note that unit tests do let you do things like alloc, because Rust tests run wit...

Totally forgot about register_contract_wasm - good call!

Just to clarify your last point - if I deploy a contract in a Rust test that does something illegal (like use floating point) with register_contract_wasm, should I expect it to fail?

(as a side note, i just wrote a contract whose only function is

    pub fn float(e: Env) -> BigInt {
        let float: f64 = 1.234;
        let temp = float * e.ledger().timestamp() as f64;
        BigInt::from_u64(&e, temp as u64)
    }

it appears to currently build and work in tests and Sandbox as well, which might be a separate issue or some compilation magic)

ruby patrol
#

That works when you build it to a .wasm file and run it with soroban-cli? thinkeyes

crisp scarab
#

Yup, when the ledger.timestamp is 100 as verified in ledger.json:

mootz12@Alexs-MBP interface_usage % soroban invoke --id 5a4d3a7529b2e2bce80ba04b9bdd2be515f79d1f187b4b0e843b1c3592ec2689 --fn float
"123"
normal lantern
#

is the VM not configured properly in tests? is it actually properly configured in core at all?

ruby patrol
#

@thorn canyon Did we potentially lose the f32 banning with the upgrade of wasmi?

thorn canyon
#

I thought not!

#

wasmi's "deterministic_only" flag is supposed to ban fp ops

#

I thought I even had a test in there for this

#

hmm maybe not

#

(I'm sorry, I did try to check this back when I was doing the last upgrade, guess it didn't make it)

ruby patrol
#

I'm pretty sure we had a test for this, I remember us trying it at one point at least.

thorn canyon
#

looks like maybe wasmi needs to be built with the "deterministic" feature?

#

sorry I'm knee deep in macro hacking at the moment .. is this urgent?