Add example transaction golden test for each era#5799
Add example transaction golden test for each era#5799koslambrou wants to merge 2 commits intomasterfrom
Conversation
| decoderEquivalenceEraSpec @AlonzoEra @(TxDats AlonzoEra) | ||
| decoderEquivalenceEraSpec @AlonzoEra @(Redeemers AlonzoEra) | ||
| Binary.txSizeSpec @AlonzoEra | ||
| Golden.spec @AlonzoEra |
There was a problem hiding this comment.
Duplicate execution.
| "golden/block.cbor" | ||
| (eraProtVerLow @AlonzoEra) | ||
| (pleBlock ledgerExamplesAlonzo) | ||
| cborAnnGoldenSpec |
There was a problem hiding this comment.
Duplicate. Now covered by new golden tests.
|
|
||
| exampleBabbageNewEpochState :: | ||
| ( BabbageEraTest era | ||
| ( BabbageEraPParams era |
There was a problem hiding this comment.
I took out BabbageEraTest because it now causes a circular dependency because we would need to import import Test.Cardano.Ledger.Babbage.Era.
A solution for this would be to split the Example.hs module into 2: Example.NewEpochState and Example.Tx. Thoughts?
|
I wasn't 100% sure where to call A future PR would be required to organize the test modules so that each era follows the same pattern. |
koslambrou
force-pushed
the
koslambrou/golden-example-tx-each-era
branch
3 times, most recently
from
8b6ba69 to
145dd64
Compare
…c` in cardano-ledger-core:testlib and generate the golden example transactions for each era. `goldenExampleEraTxCborSpec` allows us to generate a `Spec` for generating a `golden/tx.cbor` golden file out of some `Tx` provided as a parameter. Then, for each era's test-suite, we call this function to generate the golden file using the example transaction we have defined for each era. We also extended `EraTest` so that we don't need to manually call `getDataFileName` in order to get the fullpath for each era's cabal project. We also create new `Binary.Golden` modules for Mary and Babbage (previously they reused Allegra's and Alonzo's respectively, which used the wrong era's example transactions). Additionally, fix `exampleDijkstraBasedTopTx` to not add PlutusV4 scripts to `scriptTxWitsL`: PlutusV4 is not included in Dijkstra's `transaction_witness_set` CDDL, so those scripts were silently dropped during serialization, causing a roundtrip failure.
koslambrou
force-pushed
the
koslambrou/golden-example-tx-each-era
branch
from
145dd64 to
1515f46
Compare
|
|
||
| mkEraFullPath = getDataFileName | ||
|
|
||
| exampleTx = leTx ledgerExamples |
There was a problem hiding this comment.
This goes back to my in a previous PR: #5761 (comment)
For now, I don't think it is needed on its own, but at some point later it will likely be useful. So, we have a choice either start exporting it later, or export the exact same thing
example[Era]Txfrom every era. It's up to you.
That is exactly where we need this explicit export, because after this PR is merged we will remove leTx from LedgerExamples
| exampleTx = leTx ledgerExamples | |
| exampleTx = exampleShelleyTx |
Please apply the same suggestion for all eras
2 participants
Description
Add Test.Cardano.Ledger.Core.Binary.Golden.goldenExampleEraTxCborSpec in cardano-ledger-core:testlib and generate the golden example transactions for each era.
goldenExampleEraTxCborSpecallows us to generate aSpecforgenerating a
golden/tx.cborgolden file out of someTxprovided as aparameter.
Then, for each era's test-suite, we call this function to generate the
golden file using the example transaction we have defined for each era.
We also extended
EraTestso that we don't need to manually callgetDataFileNamein order to get the fullpath for each era's cabalproject.
We also create new
Binary.Goldenmodules for Mary and Babbage (previouslythey reused Allegra's and Alonzo's respectively).
Additionally, fix
exampleDijkstraBasedTopTxto not add PlutusV4 scriptsto
scriptTxWitsL: PlutusV4 is not included in Dijkstra'stransaction_witness_setCDDL, so those scripts weresilently dropped during serialization, causing a roundtrip failure.
Checklist
CHANGELOG.mdfiles updated for packages with externally visible changes.NOTE: New section is never added with the code changes. (See RELEASING.md).
.cabalandCHANGELOG.mdfiles when necessary, according to theversioning process.
.cabalfiles updated when necessary.NOTE: If bounds change in a cabal file, that package itself must have a version increase. (See RELEASING.md).
scripts/fourmolize.sh).scripts/cabal-format.sh).scripts/gen-cddl.sh)hie.yamlupdated (usescripts/gen-hie.sh).