test : Add tests for Test Utils helper methods

[yuvraj-kolkar17]

Added unit tests in test_utils.rs

Part of #3936

• editor_creates_successfully verifies editor initializes without panicking
• new_document_is_active verifies new document is created with no layers
• draw_rect_helper_creates_layer verifies drawing a rectangle creates one layer
• draw_ellipse_helper_creates_layer verifies drawing an ellipse creates one layer
• select_primary_color_does_not_add_layer verifies color selection does not add a layer
• draw_two_shapes_gives_two_layers verifies drawing two shapes creates two layers

test execute

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! 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 a suite of unit tests for the EditorTestUtils helper methods within test_utils.rs. The primary goal is to enhance the reliability of the editor's core functionalities by ensuring that editor creation, new document handling, and basic drawing operations behave as expected. These tests validate layer management during shape creation and confirm that non-drawing actions, like color selection, do not affect the layer count.

Highlights

• Editor Initialization Test: Added a test to verify that the editor initializes successfully without panicking.
• New Document Activation Test: Implemented a test to ensure that a newly created document becomes active and contains no layers initially.
• Shape Drawing Layer Creation Tests: Included tests for draw_rect and draw_ellipse helper methods, confirming that drawing each shape correctly creates a single layer.
• Color Selection Layer Test: Added a test to verify that selecting a primary color does not inadvertently add a new layer to the document.
• Multiple Shape Drawing Test: Created a test to confirm that drawing two distinct shapes (a rectangle and an ellipse) results in exactly two layers being present in the document.

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]

Code Review

This pull request introduces a new suite of asynchronous tests for the editor's core functionalities, such as creating an editor, managing documents, and drawing basic shapes like rectangles and ellipses. The tests verify that document creation and shape drawing correctly affect the layer count. The review suggests refactoring the repeated test setup logic into a helper function to improve code reuse and maintainability. It also recommends using assert_eq! for equality checks in tests for more idiomatic Rust and clearer failure messages.

[gemini-code-assist]

The test setup logic of creating an editor and a new document is repeated across multiple tests (new_document_is_active, draw_rect_helper_creates_layer, draw_ellipse_helper_creates_layer, select_primary_color_does_not_add_layer, and draw_two_shapes_gives_two_layers).

To improve code reuse and reduce boilerplate, consider extracting this into a helper function within the test module. For example:

async fn create_editor_with_new_document() -> EditorTestUtils {
    let mut editor = EditorTestUtils::create();
    editor.new_document().await;
    editor
}

Then, each test can be simplified, for instance:

#[tokio::test]
async fn new_document_is_active() {
    let editor = create_editor_with_new_document().await;
    assert_eq!(editor.active_document().metadata().all_layers().count(), 0);
}

[gemini-code-assist]

Using assert_eq! is more idiomatic in Rust for equality checks in tests. It also provides a more informative failure message by showing the left and right values if the assertion fails, which can be helpful for debugging.

Suggested change

	assert!(editor.active_document().metadata().all_layers().count() == 0);
	assert_eq!(editor.active_document().metadata().all_layers().count(), 0);

[cubic-dev-ai]

No issues found across 1 file

Confidence score: 5/5

• Automated review surfaced no issues in the provided summaries.
• No files require special attention.