Simulate endpoint tests #265
Conversation
… from genesis account
There was a problem hiding this comment.
Looking solid. My main question surrounds what to do (if anything) about simulating without signatures. My intuition is that we should support it. But if we do, then we also need to make it easy to send unsigned transactions and also to collect the results and have some method such as would_have_succeeded_but_for_signatures() (please find a better name) that easily answers the question suggested by this terrible method name.
| | 1234523 | X4Bl4wQ9rCo= | | ||
|
|
||
| @simulate | ||
| Scenario: Simulating duplicate transactions in a group |
There was a problem hiding this comment.
Similar to the above, if we want to support signature-missing simulations with the AtomicTransactionComposer, its API would need to support this and the feature tested.
| Given default transaction with parameters <amt> "<note>" | ||
| When I get the private key | ||
| And I sign the transaction with the private key | ||
| And I simulate the transaction |
There was a problem hiding this comment.
Do you think it's worth distinguishing between simulating with signed transactions and simulating without ?
If so, this step could instead by:
And I simulate-signed the transactionleaving room for the future
And I simulate-unsigned the transactionBut if the API is going to be the same (i.e. simulate just takes the transactions as they are and doesn't need special methods to handle unsigned), then we don't need to change this step.
We could also punt this to #267 and if the API changes at a later date, we would change the steps as well - though that would be a bit annoying.
There was a problem hiding this comment.
I don't think the API would change, so no need for two separate steps.
Currently, the simulate endpoint itself sends the msgpack encoded transaction (bytearray-like object). As a part of #267 , we probably need helper methods to encode unsigned transactions into msgpack, and then send that to the simulate endpoint. Currently, we have explicit checks in the SDKs to look for signatures before doing this encoding.
| When I build a payment transaction with sender "transient", receiver "transient", amount 100001, close remainder to "" | ||
| And I create a transaction with signer with the current transaction. | ||
| And I add the current transaction with signer to the composer. | ||
| Then I simulate the current transaction group with the composer |
There was a problem hiding this comment.
Similar question. Should we anticipate the following step, and therefore rename this one?
Then I simulate-signed the current transaction group with the composer
* Add unsigned transaction simulation tests * Add another test case for multiple unsigned txns
|
Since we merged algorand/py-algorand-sdk#420 and algorand/py-algorand-sdk#445 in, it makes sense to merge this in as well. |
Adds tests for:
Also changes the following (not-necessarily related to simulate)
RandomByteTEAL contract to call a bad inner txnCloses #270
Related SDK PRs