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
{{ message }}
This repository has been archived by the owner on Apr 23, 2024. It is now read-only.
Generating these XDRs manually has helped us gain some confidence on our code's ability to parse real result meta, but it isn't going to scale if we need to generate it for every test we write.
Any tests we write in the sdk/agent need the result and meta XDR because the agent only progresses state by circulating submitting transactions back into the state machines ingestion functionality. Therefore any test we write needs to generate these files unless we write tests that fiddle with the internal state of the channel.
So that we can continue to write outside-in tests as much as possible I think we should write some test helper functions that take a built transactions and return a result XDR or result meta XDR for different conditions. The XDR they generate doesn't need to be perfect, but just sufficient. We will write integration tests (#268) separately to the majority of our tests that will validate real XDR in the main use cases.
I'm thinking something like:
package txbuildtest
// BuildResult returns a result XDR base64 encoded that is successful or not based on the input parameter.funcBuildResult(successbool) string// BuildResultMeta returns a result meta XDR base64 encoded that contains arbitrary operations that result in the given account and trustline state.funcBuildResultMeta(txChangesAfter xdr.LedgerEntryChanges) string
Maybe we could make this even easier, such as txbuildtest.BuildResultMeta(txXDR), but I'm not sure that is possible.
The text was updated successfully, but these errors were encountered:
We're starting to write more and more tests that require writing valid result xdr and result meta xdr.
For the few tests we've written so far using XDR that we've manually generated and inserted into tests has worked pretty well. For example:
https://github.com/stellar/experimental-payment-channels/blob/48ed2c39c73ec751ef38a15109d653a40bd2eedf/sdk/state/ingest_test.go#L255
Generating these XDRs manually has helped us gain some confidence on our code's ability to parse real result meta, but it isn't going to scale if we need to generate it for every test we write.
Any tests we write in the
sdk/agent
need the result and meta XDR because the agent only progresses state by circulating submitting transactions back into the state machines ingestion functionality. Therefore any test we write needs to generate these files unless we write tests that fiddle with the internal state of the channel.So that we can continue to write outside-in tests as much as possible I think we should write some test helper functions that take a built transactions and return a result XDR or result meta XDR for different conditions. The XDR they generate doesn't need to be perfect, but just sufficient. We will write integration tests (#268) separately to the majority of our tests that will validate real XDR in the main use cases.
I'm thinking something like:
Maybe we could make this even easier, such as
txbuildtest.BuildResultMeta(txXDR)
, but I'm not sure that is possible.The text was updated successfully, but these errors were encountered: