Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fuzz: refactor fixture processing harnesses to use &mut self #77

Merged
merged 6 commits into from
Jan 15, 2025

Conversation

buffalojoec
Copy link
Collaborator

When working with fixtures, it's sometimes necessary to configure Mollusk's program cache before running some set of fixtures.

In the current implementation, functions such as process_and_validate_fixture are associated functions, so they vend their own new Mollusk instance internally and use that for processing the fixture, giving the developer no opportunity to configure the program cache (or any other configurations).

This change makes these functions methods using &mut self, which causes the loaded fixture to update the current Mollusk instance's configurations based on the fixture.

A few notes:

  • For any developers who do not wish to alter their Mollusk instance based on loaded fixtures, the load_fixture function will no longer vend a Mollusk instance, but the components themselves, allowing developers to do with the components what they wish.
  • The run_checks method on the InstructionResult type has been made public, in case comparing all checks in process_and_validate_fixture (or any other Mollusk method for that matter) is too strict. Now, one could run just a subset of checks on the returned result from, say, process_fixture.

cc @febo

@buffalojoec buffalojoec added the v2.0 Backport to solana-v2.0 label Jan 13, 2025
/// Validate the return data.
ReturnData,
/// Validate all resulting accounts.
AllResultingAccounts {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it make sense to have a variant without any data representing the case where you want to check everything from the resulting accounts? It would be a simpler way to do that (no need to add the bool values) and it might be the common case.

Not so sure about the naming that we could have, but maybe something along the lines:

...
/// Validates all resulting accounts.
ResultingAccounts,
/// Validates specific fields of all resulting accounts.
ResultingAccountsFields {
        /// Whether or not to validate each account's data.
        data: bool,
        /// Whether or not to validate each account's lamports.
        lamports: bool,
        /// Whether or not to validate each account's owner.
        owner: bool,
        /// Whether or not to validate each account's space.
        space: bool,
},
/// Validates specific fields of a subset resulting accounts.
ResultingAccountsSubset {
        /// The addresses on which to apply the validation.
        addresses: Vec<Pubkey>,
        /// Whether or not to validate each account's data.
        data: bool,
        /// Whether or not to validate each account's lamports.
        lamports: bool,
        /// Whether or not to validate each account's owner.
        owner: bool,
        /// Whether or not to validate each account's space.
        space: bool,
},
/// Validates specific fields of resulting accounts _except_ the provided addresses.
ResultingAccountsExcept {
        /// The addresses on which to _not_ apply the validation.
        ignore_addresses: Vec<Pubkey>,
        /// On non-ignored accounts, whether or not to validate each account's
        /// data.
        data: bool,
        /// On non-ignored accounts, whether or not to validate each account's
        /// lamports.
        lamports: bool,
        /// On non-ignored accounts, whether or not to validate each account's
        /// owner.
        owner: bool,
        /// On non-ignored accounts, whether or not to validate each account's
        /// space.
        space: bool,
    },
}

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added helpers for this in my most recent commit. Nice suggestion!

Copy link
Contributor

@febo febo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great! Left a small suggestion.

@febo
Copy link
Contributor

febo commented Jan 13, 2025

Run a test with the FixtureCheck and they work fine.

@buffalojoec buffalojoec merged commit ba391d1 into main Jan 15, 2025
4 checks passed
@buffalojoec buffalojoec deleted the fixtures-luv branch January 15, 2025 02:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
v2.0 Backport to solana-v2.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants