fungible conformance tests: Inspect and Mutate

[liamaharon]

Partial: paritytech/polkadot-sdk#225

Implements conformance tests for fungible traits Inspect and Mutate.

• Pattern for creating a function that accepts something implementing Inspect + Mutate

  •   pub fn something<T, AccountId, Balance>()
      where
          T: Mutate<AccountId> + Inspect<AccountId, Balance = Balance>,
          AccountId: AtLeast8BitUnsigned,
          Balance: AtLeast8BitUnsigned + Debug,
      {}

• Implement inspect and mutate conformance tests (frame/support/src/traits/tokens/fungible/conformance_tests/inspect_mutate.rs)

• Test conformance tests against balances (frame/balances/src/tests/fungible_conformance_tests.rs)

  •  cargo test --package pallet-balances -- tests::fungible_conformance_tests:: --nocapture
    

• Create a macro to generate test cases wrapped with some logic

[sam0x17]

This should lend itself well to a simple macro. Based on your description I think you should be able to write a regular proc macro that accepts those args (I generally recommend making a MyUseCaseArgs struct and using derive_syn_parse to get an automatic Parse implementation for it, it can even do things like optional fields etc). The proc macro would then expand to a test case like the one you are writing.

you mention that Balance and AccountId need to be passed. Are these always just <Test as frame_system::Config>::AccountId and <Test as pallet_balances::Config>::Balance or is there some variation there necessitating them being part of the input. I'm assuming based on your examples that these are always the same? Anyway, here is a contrived example

If the inputs are just a few idents or paths (or any syn type separated by commas with some optional args at the end), you could have something like:

#[derive(derive_syn_parse::Parse)]
struct InspectMutateConformanceTestArgs {
    some_ident: syn::Ident,
    _comma1: syn::token::Comma,
    some_path: syn::Path,
    _comma2: Option<syn::token::Comma>,
    #[parse_if(_comma2.is_some())]
    optional_path: Option<syn::Path>,
}

#[proc_macro]
pub fn inspect_mutate_conformance_tests(tokens: TokenStream) -> TokenStream {
    let args = parse_macro_input!(tokens as InspectMutateConformanceTestArgs);
    let test_ident = quote::format_ident!("mint_into_{}", args.some_ident);
    // other stuff with args ...
    quote::quote! {
        #[test]
        fn #test_ident() {
            ExtBuilder::default().build_and_execute_with(|| {
                conformance_tests::inspect_mutate::#test_ident::<
                    Balances,
                    <Test as frame_system::Config>::AccountId,
                    <Test as pallet_balances::Config>::Balance,
                >();
            });
        }
    }
}

Something vaguely like that, I'm just not 100% clear on what the args would be, but the above would let you parse args like this:

inspect_mutate_conformance_tests!(an_ident, some::cool_path);

And optionally have a third field like:

inspect_mutate_conformance_tests!(another_ident, different::path, an::optional::path);

Hope this helps. If you can give me exact desired usage of the proc macro I can give you something tighter

[KiChjang]

I think something as simple as this doesn't require a proc macro, and can still be easily done using a declarative macro using macro_rules!:

macro_rules! inspect_mutate_conformance_tests {
    ($name:ident, $some_path:path $(, $optional_path:path)?) => /* macro code goes here */
}

And with the clever usage of paste::paste!, we can create custom names for the tests as well using declarative macros.

[sam0x17]

Yes I agree a macro_rules would be fine here unless you want to be very strict about what you are passing in which looks like it is not necessary if it's idents and paths. A proc macro would be nice if you want to assert that one of the inputs is a very specific syn type, for example

edit: although concating idents is a hell of a lot easier in proc macros...

[liamaharon]

Ahh thanks all, really appreciate the examples.

Originally I had been thinking about the macro living with the generalised tests, but I see now it would be much more simple if it was with the implementation, allowing the implementation to customise the environment the tests are run in without anything too complicated.

It also would allow the implementor to run the same sets of test with different environment parameters, e.g. balances could easily run the tests with different values for existential_deposit (perhaps opportunity for more fuzzing). 👌

[liamaharon]

@xlc if you have time it would be nice to get your eyes on this given you're likely to use it with orml-tokens.

and @gavofyork also curious to get your eyes on this if you have time, given it's your issue I'd like to check that this satisfies the requirements you had in mind.

[gavofyork]

Looks good.