Skip to content

test(utils): add unit tests for ValidatorStatus and getValidatorStatus#298

Open
lodekeeper-z wants to merge 2 commits into
ChainSafe:mainfrom
lodekeeper-z:test/validator-status
Open

test(utils): add unit tests for ValidatorStatus and getValidatorStatus#298
lodekeeper-z wants to merge 2 commits into
ChainSafe:mainfrom
lodekeeper-z:test/validator-status

Conversation

@lodekeeper-z

Copy link
Copy Markdown
Contributor

Summary

Add 12 unit tests for validator_status.zig covering the complete validator lifecycle state machine and utility functions.

Tests added

Test Coverage
pending_initialized activation_epoch > current, eligibility == FAR_FUTURE
pending_queued activation_epoch > current, eligibility < FAR_FUTURE
active_ongoing active, exit_epoch == FAR_FUTURE
active_exiting active, exit_epoch < FAR_FUTURE, not slashed
active_slashed active, exit_epoch < FAR_FUTURE, slashed
exited_unslashed exited, not slashed
exited_slashed exited, slashed
withdrawal_possible withdrawable, effective_balance > 0
withdrawal_done withdrawable, effective_balance == 0
toString tagName roundtrip
fromString string → enum + invalid input
matchesCategory all 4 categories + unknown

Motivation

validator_status.zig had 0 test coverage. It's used by the NAPI getValidatorStatus binding and will be used by the upcoming getValidatorsByStatus method.

🤖 Generated with AI assistance

Add 12 unit tests covering:
- All 9 validator lifecycle states (pending_initialized through withdrawal_done)
- toString/fromString roundtrip
- matchesCategory for all 4 categories (pending, active, exited, withdrawal)
- Invalid category returns false
- Invalid string returns null

🤖 Generated with AI assistance
@lodekeeper-z lodekeeper-z requested a review from a team as a code owner March 30, 2026 01:23
@gemini-code-assist

Copy link
Copy Markdown
Contributor

Summary of Changes

Hello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request introduces unit testing for the validator status logic, which previously lacked test coverage. By implementing a suite of tests covering the full validator lifecycle and utility methods, this change ensures the reliability of the validator status state machine, which is critical for upcoming NAPI bindings and related functionality.

Highlights

  • Test Coverage: Added 12 comprehensive unit tests to validator_status.zig to ensure the validator lifecycle state machine and utility functions behave as expected.
  • Helper Utilities: Introduced a makeValidator helper function to simplify the creation of mock validator objects for testing purposes.

🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature Command Description
Code Review /gemini review Performs a code review for the current pull request in its current state.
Pull Request Summary /gemini summary Provides a summary of the current pull request in its current state.
Comment @gemini-code-assist Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help /gemini help Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here.

Footnotes

  1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution.

@gemini-code-assist gemini-code-assist Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Code Review

This pull request adds a suite of unit tests for validator status functions and methods in validator_status.zig. The review feedback identifies several style guide violations in the test implementation, including the need for in-place initialization of large structs via out-pointers, adherence to the 100-character line limit, and the use of descriptive variable names instead of abbreviations.

Comment on lines +90 to +114
fn makeValidator(
activation_eligibility_epoch: u64,
activation_epoch: u64,
exit_epoch: u64,
withdrawable_epoch: u64,
slashed: bool,
effective_balance: u64,
) Validator.Type {
return .{
.pubkey = [_]u8{0} ** 48,
.withdrawal_credentials = [_]u8{0} ** 32,
.effective_balance = effective_balance,
.slashed = slashed,
.activation_eligibility_epoch = activation_eligibility_epoch,
.activation_epoch = activation_epoch,
.exit_epoch = exit_epoch,
.withdrawable_epoch = withdrawable_epoch,
};
}

test "getValidatorStatus - pending_initialized" {
// activation_epoch > current_epoch AND activation_eligibility_epoch == FAR_FUTURE
const v = makeValidator(constants.FAR_FUTURE_EPOCH, constants.FAR_FUTURE_EPOCH, constants.FAR_FUTURE_EPOCH, constants.FAR_FUTURE_EPOCH, false, 32_000_000_000);
try testing.expectEqual(ValidatorStatus.pending_initialized, getValidatorStatus(&v, 100));
}

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

medium

This new test code has a few violations of the repository's style guide:

  1. In-place initialization for large structs: Validator.Type is a large struct. Helper functions that create instances of it, like makeValidator, should use an out-pointer to initialize the struct in-place, rather than returning it by value.
  2. Line length: Function calls with many arguments, like the calls to makeValidator, exceed the 100-column limit and should be formatted across multiple lines.
  3. No abbreviated variable names: The variable v is an abbreviation. The style guide requires descriptive names like validator.

Please apply these changes throughout the new test code. Here is an example of how makeValidator and the first test should be refactored:

fn makeValidator(
    target: *Validator.Type,
    activation_eligibility_epoch: u64,
    activation_epoch: u64,
    exit_epoch: u64,
    withdrawable_epoch: u64,
    slashed: bool,
    effective_balance: u64,
) void {
    target.* = .{
        .pubkey = [_]u8{0} ** 48,
        .withdrawal_credentials = [_]u8{0} ** 32,
        .effective_balance = effective_balance,
        .slashed = slashed,
        .activation_eligibility_epoch = activation_eligibility_epoch,
        .activation_epoch = activation_epoch,
        .exit_epoch = exit_epoch,
        .withdrawable_epoch = withdrawable_epoch,
    };
}

test "getValidatorStatus - pending_initialized" {
    // activation_epoch > current_epoch AND activation_eligibility_epoch == FAR_FUTURE
    var validator: Validator.Type = undefined;
    makeValidator(
        &validator,
        constants.FAR_FUTURE_EPOCH,
        constants.FAR_FUTURE_EPOCH,
        constants.FAR_FUTURE_EPOCH,
        constants.FAR_FUTURE_EPOCH,
        false,
        32_000_000_000,
    );
    try testing.expectEqual(ValidatorStatus.pending_initialized, getValidatorStatus(&validator, 100));
}
References
  1. Construct larger structs in-place by passing an out pointer during initialization. The Validator.Type struct is large, so it should be initialized in-place to avoid moving the object, which can lead to undesirable stack growth. (Lines 318-325, 326-351) (link)
  2. Hard limit all line lengths to at most 100 columns. To wrap a function call, add a trailing comma and run zig fmt. (Lines 400-403) (link)
  3. Do not abbreviate variable names. Use descriptive names to improve code clarity. (Line 221) (link)

Remove extra blank line caught by CI fmt check.

🤖 Generated with AI assistance
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants