Gno: An interpreted, stack-based Go virtual machine to build succinct and composable apps + Gno.land: a blockchain for timeless code and fair open-source
As discussed in https://github.com/gnolang/gno/pull/1471, I believe txtar tests should always start with a fresh chain, and not have initial accounts or initial deployments (in genesis). The reason for this being, txtar environments should be heavily controlled by the test maker, and not have unexpected premines and predeploys when the node starts within the test.
Instead, I propose we introduce functionality to control these features, similar to what @deelawn is doing in #1471. This way, the test maker can actually choose to premine or predeploy specific accounts or contracts. It is more explicit, and breaks away from the behavior we have lurking in the codebase of stuff happening behind the scenes without the user's knowledge (especially with chain initialization).
Description
As discussed in https://github.com/gnolang/gno/pull/1471, I believe
txtar
tests should always start with a fresh chain, and not have initial accounts or initial deployments (in genesis). The reason for this being,txtar
environments should be heavily controlled by the test maker, and not have unexpected premines and predeploys when the node starts within the test.Instead, I propose we introduce functionality to control these features, similar to what @deelawn is doing in #1471. This way, the test maker can actually choose to premine or predeploy specific accounts or contracts. It is more explicit, and breaks away from the behavior we have lurking in the codebase of stuff happening behind the scenes without the user's knowledge (especially with chain initialization).
Looking for opinions @moul @gfanton @ajnavarro