Stake instruction tests #24
Conversation
2501babe
force-pushed
the
stake-instruction-tests
branch
from
1b74c3b to
e1bb8a5
Compare
| fn mollusk_native() -> Mollusk { | ||
| let mut mollusk = Mollusk::default(); | ||
| mollusk | ||
| .feature_set | ||
| .deactivate(&stake_raise_minimum_delegation_to_1_sol::id()); | ||
| mollusk | ||
| } | ||
|
|
||
| fn mollusk_bpf() -> Mollusk { | ||
| let mut mollusk = Mollusk::new(&id(), "solana_stake_program"); | ||
| mollusk | ||
| .feature_set | ||
| .deactivate(&stake_raise_minimum_delegation_to_1_sol::id()); | ||
| mollusk | ||
| } |
There was a problem hiding this comment.
Sorry! I need to update the documentation, but you can actually use one Mollusk instance if you wanted. It doesn't map to a program anymore. new is just a convenience method to create a new instance and load a BPF program into the cache, but a Mollusk instance comes with a loaded cache and can be pointed at any program in the cache, doesn't matter if you use default or new.
The program to invoke is dictated by the instruction's program ID.
There was a problem hiding this comment.
i believe what im doing here is correct (note that this branch uses a local version of mollusk on my machine that includes all three of my open prs). mollusk_native() loads no program so it uses the native stake program, mollusk_bpf() loads the bpf stake program which overrides the native. they have the same program id so there isnt a way to discriminate between them otherwise
There was a problem hiding this comment.
Ahh I see, so the main purpose being to overwrite the stake program in the second one. Yeah, I think you've got it right then.
| create_account_shared_data_for_test(&clock::Clock::default()) | ||
| } else if rewards::check_id(pubkey) { | ||
| create_account_shared_data_for_test(&rewards::Rewards::new(0.0)) | ||
| } else if stake_history::check_id(pubkey) { | ||
| create_account_shared_data_for_test(&StakeHistory::default()) | ||
| } else if stake_config::check_id(pubkey) { | ||
| config::create_account(0, &stake_config::Config::default()) | ||
| } else if epoch_schedule::check_id(pubkey) { | ||
| create_account_shared_data_for_test(&EpochSchedule::default()) | ||
| } else if rent::check_id(pubkey) { | ||
| create_account_shared_data_for_test(&Rent::default()) |
There was a problem hiding this comment.
It's still a bit annoying to do, but you do have this API for keyed sysvar accounts available from the library:
https://github.com/buffalojoec/mollusk/blob/0c7b0edfe5788e9a6892d2c4eb60d43390c7175f/harness/src/sysvar.rs#L101-L134
2501babe
force-pushed
the
stake-instruction-tests
branch
from
3deeade to
65b7fb7
Compare
|
the branch rename seems to have dropped this prs connection to ci so im gonna merge it as-is once i can switch from local mollusk and then see what needs fixed in-flight. i think ci is still just fmt/clippy and doesnt run tests so ill have to add some workflow files anyway edit: i didnt get ci for a new pr either so i guess we just dont have it right now, its immaterial tho since theres nothing important for ci to do yet |
port all tests (except one that makes no sense) from monorepo stake_instruction.rs. we accomplish this by:
InstructionErrortoProgramErrorprocess_instruction,process_instruction_as_one_arg, etc to use mollusk to emulate the previous rawInvokeContextcreation/usagetest_casevariants. because we no longer have features, minimum delegation is hardcoded as off in the program and cannot be tested. if we ever get consensus on activating it, we can reenable by addingtest_caseusing whatever mechanism is chosentest_casevariants for bpf stake and native stake. this ensures the same tests pass against both programsStakeHistory::default(). the details are somewhat arcane and do not (and could never possibly) occur on a live cluster, but these tests set up an invalidStakeHistoryfull of epoch 0 entries, which the stake history syscall rejects as invalid, when what they really want is a nonexistant stake historythere are two (and only two) places where we behave differently depending on which program is being tested. this is because we fixed a minor bug and expect to see an
InvalidAccountOwnererror instead ofIncorrectProgramIdwhen an owner is invalid. these can be seen by grepping foris_bpf()