If I'm not mistaken, the typical mockchain testing flow looks like (as suggested by the docs):
mockChainSucceeds . failOnError $ do
let tx = buildSomeTx
balanceAndSubmit mempty Wallet.w1 tx TrailingChange []
This looks all well and good. There's a couple errors being handled here already as suggested by the function names. However, balanceAndSubmit, for whatever reason, produces both a MonadError (BalanceTxError) and also returns an error Either (SendTxError era) a.
It looks to me like said return value is silently ignored at mockChainSucceeds since it does not actually care about the value held within the MockChainT.
This technically falls under user error. So I'm not expecting it to be reworked but it does seem like questionable API design. At the very least, perhaps the docs should avoid suggesting this pattern (i.e any pattern where balanceAndSubmit return value is unhandled).
If I'm not mistaken, the typical mockchain testing flow looks like (as suggested by the docs):
This looks all well and good. There's a couple errors being handled here already as suggested by the function names. However,
balanceAndSubmit, for whatever reason, produces both aMonadError(BalanceTxError) and also returns an errorEither (SendTxError era) a.It looks to me like said return value is silently ignored at
mockChainSucceedssince it does not actually care about the value held within theMockChainT.This technically falls under user error. So I'm not expecting it to be reworked but it does seem like questionable API design. At the very least, perhaps the docs should avoid suggesting this pattern (i.e any pattern where
balanceAndSubmitreturn value is unhandled).