Refactor coin-based contract instruction tests #779
Conversation
Dentosal
changed the title
Dentosal
changed the title
| #[test_case(vec![(op::burn, 1, 0)] => RunResult::Panic(PanicReason::NotEnoughBalance); "Burn nonexisting 1")] | ||
| #[test_case(vec![(op::burn, Word::MAX, 0)] => RunResult::Panic(PanicReason::NotEnoughBalance); "Burn nonexisting Word::MAX")] | ||
| #[test_case(vec![(op::mint, Word::MAX, 0), (op::mint, 1, 0)] => RunResult::Panic(PanicReason::BalanceOverflow); "Mint overflow")] | ||
| #[test_case(vec![(op::mint, Word::MAX, 0), (op::burn, 1, 0), (op::mint, 2, 0)] => RunResult::Panic(PanicReason::BalanceOverflow); "Mint,Burn,Mint overflow")] |
There was a problem hiding this comment.
Hmm, maybe we want to have just separate bunch of tests for mint and burn to test the overflow of the SubId.
There was a problem hiding this comment.
Why is that? Are there more cases you'd like to test?
fuel-vm/src/tests/coins.rs
Outdated
| #[test_case(1, 0, 10, 5 => RunResult::Panic(PanicReason::TransferZeroCoins); "Cannot transfer 0 coins to non-empty other")] | ||
| #[test_case(0, 0, 10, 0 => RunResult::Panic(PanicReason::TransferZeroCoins); "Cannot transfer 0 coins to self")] | ||
| #[test_case(1, 1, 10, 0 => RunResult::Success((9, 1)); "Can transfer 1 coins to other")] | ||
| #[test_case(0, 1, 10, 0 => RunResult::Success((10, 0)); "Can transfer 1 coins to self")] |
There was a problem hiding this comment.
It seems the self transfers doesn't affect values in Success. Maybe we want to list all balances of all contract there for clarity of the expected result.
There was a problem hiding this comment.
I don't understand. The balance must stay the same, as the balance is decreased and then increased again by the same amount. What other balances would help?
| } | ||
|
|
||
| #[test_case(None, None => RunResult::Success(()); "Normal case works")] | ||
| #[test_case(Some(Word::MAX - 31), None => RunResult::Panic(PanicReason::MemoryOverflow); "$rA + 32 overflows")] |
There was a problem hiding this comment.
Do we want to return MemoryOverflow instead of ArifmethicOverflow?
There was a problem hiding this comment.
Yes. MemoryOverflow is what happens when an operation conceptually exceeds VM_MAX_RAM. The behavior is quite consistent; ArithmeticOverflow is only used by the ALU operations when they overflow. For instance, we never panic with ArithmeticOverflow when WRAPPING flag is set.
Work towards #746
Checklist
Before requesting review