You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For writing differential tests it is important that objects like a Vec, or Address, or any other SDK value, can be compared across Envs. This is because ideally when you are doing differential testing you can start both sets of test cases running in their own Envs so that things like Addresses, IDs, etc are all identical for easy comparison.
Today, if you run the above, it'll result in a panic when comparing the auths1 and auths2, and events1 and events2. The panic occurs because of the same env check here, and in similar places in other types:
The check is reasonable, because the cmp functions of all the sdk types calls the env and asks the env to do the comparison.
When the cmp functions are called, if currently not building for wasm, the code could check if currently in the same env, and if not, convert the sdk type to it's XDR equivalent, and compare those.
What alternatives are there?
To expect people to do differential testing inside the same env, but that seems unrealistic. It would not be possible to just simply compare two auths or two events objects, becauses the addresses would be different.
The text was updated successfully, but these errors were encountered:
### What
Updates every type that is a handle to a type stored in the host so that
it is comparable with itself via a conversion to an `ScVal` even when
the values are across different `Env`s.
### Why
To make it much easier to perform differential testing.
Today it is not possible to compare values of an SDK type, when the
values are a handles to values stored on different hosts. This is
because the comparison of SDK types is supported by calling through to
the host. It makes sense for comparison to work this way because the
value is on the host side.
However when writing tests it is helpful to be able to compare SDK types
even if they belong to different Envs. The main use case is differential
tests, where two sequences of invokes should be comparable.
In tests the efficiency of the comparison is not important, so
converting to ScVal is an okay way to fall back to do the comparison. In
some ways this is a bit of a hack, but it's the least disruptive way of
supporting the comparison, and avoids introducing a ton of code to the
Env that would otherwise be out of place.
Talking to @graydon we have quite solid testing around the consistency
of ScVal and Val values, so converting the Vals to ScVal to do the
comparison is safe.
Close#1360
Feature request
For writing differential tests it is important that objects like a Vec, or Address, or any other SDK value, can be compared across Envs. This is because ideally when you are doing differential testing you can start both sets of test cases running in their own Envs so that things like Addresses, IDs, etc are all identical for easy comparison.
I'd like to be able to do this:
Today, if you run the above, it'll result in a panic when comparing the auths1 and auths2, and events1 and events2. The panic occurs because of the same env check here, and in similar places in other types:
rs-soroban-sdk/soroban-sdk/src/address.rs
Lines 81 to 88 in f0e653e
The check is reasonable, because the cmp functions of all the sdk types calls the env and asks the env to do the comparison.
When the cmp functions are called, if currently not building for wasm, the code could check if currently in the same env, and if not, convert the sdk type to it's XDR equivalent, and compare those.
What alternatives are there?
To expect people to do differential testing inside the same env, but that seems unrealistic. It would not be possible to just simply compare two auths or two events objects, becauses the addresses would be different.
The text was updated successfully, but these errors were encountered: