Add Cursor Rule for Fixture Monkey Test Writing Guidelines

[seongahjo]

Summary

Add a Cursor rule that guides developers to write tests using Fixture Monkey effectively, following established patterns and best practices found in the codebase.

Description

Currently, developers new to Fixture Monkey may struggle with:

• Choosing the right FixtureMonkey configuration for their test scenarios
• Understanding when to use giveMeOne() vs giveMeBuilder() vs giveMe()
• Properly setting up test fixtures with appropriate customizations
• Following consistent patterns for test data generation

This issue proposes creating a Cursor rule that provides guidance for writing effective tests with Fixture Monkey. The rule should reference successful patterns from the existing test suite, particularly from files like JavaTest.java and documentation examples.

Key areas the rule should cover:

• FixtureMonkey instance creation and configuration
• Choosing appropriate generation methods
• Customizing test objects with set(), size(), and other builder methods
• Working with generic types and complex objects
• Best practices for test data consistency

Expected Usage

Before (without the rule):

@Test
void testUserService() {
    // Developer might write verbose setup code
    User user = new User();
    user.setName("Test User");
    user.setAge(25);
    user.setEmail("test@example.com");
    
    // Test logic...
}

After (with Cursor rule guidance):

@Test
void testUserService() {
    // Cursor suggests using Fixture Monkey
    FixtureMonkey fixtureMonkey = FixtureMonkey.builder()
        .objectIntrospector(ConstructorPropertiesArbitraryIntrospector.INSTANCE)
        .defaultNotNull(true)
        .build();
    
    User user = fixtureMonkey.giveMeBuilder(User.class)
        .set("age", 25)
        .sample();
    
    // Test logic...
}

Complex scenario guidance:

@Test
void testProductWithMultipleOptions() {
    // Rule guides proper generic type handling and collection customization
    Product product = fixtureMonkey.giveMeBuilder(Product.class)
        .size("options", 3)
        .set("options[0]", "premium")
        .set("price", Arbitraries.longs().greaterThan(0))
        .sample();
}

Implementation Hints

1. Study existing patterns: Examine JavaTest.java and other test files to identify common patterns
2. Reference documentation: Use examples from the docs/ directory for best practices
3. Create rule structure: Follow the format of existing .cursor/rules/*.mdc files
4. Include code examples: Provide before/after examples for common scenarios
5. Add decision trees: Help developers choose between different Fixture Monkey methods

Validation Requirements

The rule must be tested across 5 different projects to ensure effectiveness:

1. Create test scenarios: Apply the rule to 5 different Java/Kotlin projects with varying complexity
2. Measure effectiveness: Document how well the rule guides developers to use Fixture Monkey
3. Collect feedback: Gather feedback on rule clarity and usefulness from different project contexts
4. Iterate based on results: Refine the rule based on real-world usage patterns
5. Document findings: Include a summary of validation results in the PR

Suggested test projects:

• Simple Spring Boot REST API project
• Complex domain model with JPA entities
• Microservice with multiple data transfer objects
• Legacy codebase with existing manual test setup
• Kotlin project using data classes

Validation criteria:

• Rule successfully guides developers to use Fixture Monkey instead of manual object creation
• Developers can easily choose appropriate Fixture Monkey methods
• Generated test code follows established best practices
• Rule reduces time spent on test data setup
• Code suggestions are contextually appropriate

Files to Reference

• fixture-monkey-tests/java-tests/src/test/java/com/navercorp/fixturemonkey/tests/java/JavaTest.java - For test patterns
• docs/content/v1.1.x/docs/get-started/ - For beginner-friendly examples
• docs/content/v1.1.x/docs/generating-objects/fixture-monkey.md - For API usage patterns
• docs/content/v1.1.x/docs/customizing-objects/ - For customization examples

Good First Issue Because

This issue is perfect for beginners because:

• Pattern-following: The task involves analyzing existing successful patterns rather than creating new functionality
• Clear examples: Abundant test files and documentation provide concrete examples to follow
• Documentation-focused: Primarily involves writing clear, helpful documentation
• Low risk: Creating a Cursor rule doesn't affect the core codebase functionality
• Learning opportunity: Contributors will gain deep understanding of Fixture Monkey best practices
• Real-world validation: Testing across multiple projects provides valuable hands-on experience

The existing .cursor/rules/fixture-monkey-gfi-rule.mdc provides a clear template to follow, and the extensive test suite offers plenty of real-world examples to reference.

If you're interested

1. Comment below to let us know you'd like to work on this
2. Study the existing patterns in the test files and documentation
3. Prepare test projects or identify 5 existing projects for validation
4. Ask questions if you need clarification on any Fixture Monkey concepts

We're here to help guide you through the process! 🚀

Deliverables

• Cursor rule file (.cursor/rules/fixture-monkey-test-writing-rule.mdc)
• Validation report documenting testing across 5 projects
• Before/after code examples from real project usage
• Recommendations for rule improvements based on validation results

[tigermint]

Hi! 👋

I'm a beginner contributor and would love to try this as my first contribution!
I haven't used Fixture Monkey before, but this looks like a great way to learn while contributing.

I plan to study the existing patterns and documentation first, then create the .mdc rule file.
Quick question: should I create the .cursor directory structure from scratch since it doesn't exist yet?

Thanks! 😊

[seongahjo]

@tigermint
Hi.

Thank you to pay an attention to contributing.

should I create the .cursor directory structure from scratch since it doesn't exist yet?

Sure, but what about using 'cursor' rather than '.cursor' to avoid forcing the use of the cursor rule when contributing to Fixture Monkey?

Please check that you meet the requirements listed under 'Validation Requirements'.

Thank you.

[tigermint]

@seongahjo

Thanks for the clarification! I'll use the cursor/ directory structure as suggested.

could you provide some guidance on how to effectively test the .mdc rule file?
Should I manually test it in Cursor IDE across the 5 project types, or is there a specific workflow you'd recommend for validating the rule suggestions?

Thanks! 🙏

[seongahjo]

@tigermint
As far as I know, there is no effective workflow for testing such scenarios. If you know of one, please suggest it.

I plan to test it manually.

[tigermint]

@seongahjo

I've submitted PR #1195 for this issue.
Could you please review it when you have time?

The PR includes:

• Cursor rule file for Fixture Monkey test writing guidelines
• Validation across 5 different project types
• Before/after examples and documentation

If there are any parts that need improvement or additional elements I should include, I'd really appreciate your advice!

Thanks! 🙏

[YongGoose]

I think it could be a helpful reference

• https://github.com/PatrickJS/awesome-cursorrules/tree/main