IllegalArgumentException when generating non-integer numeric values with equal min and max values

[Seol-JY]

Describe the bug

When trying to generate test values using FixtureMonkey, an IllegalArgumentException is thrown if the minimum and maximum values are equal and the borders are not included (from jqwik). This issue affects BigDecimal and floating-point types (float, double) when using similar validation constraints.

Your environment

• version of Fixture Monkey: 1.1.5
• version of Java: 17

Steps to reproduce

1. Create a test using FixtureMonkey where BigDecimal or floating-point (float, double) values are generated
2. Set minimum and maximum values to be equal (e.g., 2.0)
3. The borders are not included in the range

class TEST {
    private Validator validator;

    @BeforeEach
    void setUp() {
        ValidatorFactory factory = Validation.buildDefaultValidatorFactory();
        validator = factory.getValidator();
    }

    @Test
    void success() {
        A object = new A(new BigDecimal("2"));

        Set<ConstraintViolation<A>> violations = validator.validate(object);
        assertThat(violations).isEmpty(); // [SUCCESS]
    }

    @Test
    void fail() {
        FixtureMonkey sut = FixtureMonkey.builder()
            .plugin(new JakartaValidationPlugin())
            .build();

        sut.giveMeOne(A.class); // [ERROR] If min value [2.0] is equal to max value [2.0] borders must be included.
    }

    public static class A {
        public A() {}

        public A(BigDecimal value) {
            this.value = value;
        }

        @NotNull
        // The same exception occurs with:
        // - @Min @Max annotations
        // - float/double types with similar constraints        
        @DecimalMax(value = "2.0")
        @DecimalMin(value = "2.0")
        private BigDecimal value;     

        public BigDecimal getValue() {
            return value;
        }

        public void setValue( BigDecimal value) {
            this.value = value;
        }
    }
}

If min value [2.0] is equal to max value [2.0] borders must be included.
java.lang.IllegalArgumentException: If min value [2.0] is equal to max value [2.0] borders must be included.
	at net.jqwik.engine.properties.Range.of(Range.java:18)
	at net.jqwik.engine.properties.arbitraries.DefaultBigDecimalArbitrary.between(DefaultBigDecimalArbitrary.java:57)
	at net.jqwik.engine.properties.arbitraries.DefaultBigDecimalArbitrary.lessOrEqual(DefaultBigDecimalArbitrary.java:68)
	at com.navercorp.fixturemonkey.api.jqwik.JqwikJavaArbitraryResolver.bigDecimals(JqwikJavaArbitraryResolver.java:476)

Expected behaviour

When minimum and maximum values are equal (e.g., 2.0), the test data should be generated successfully.
The generated test data should match the actual validation behavior
This will ensure consistent behavior between test data generation and actual validation logic.

Actual behaviour

The system throws an IllegalArgumentException during test data generation, preventing the creation of test cases with equal minimum and maximum values. This causes a mismatch between test data generation and actual validation behavior.

If this exception is not intended behavior, please let me know if I can submit a PR for the fix!

The root cause appears to be the incorrect handling of the inclusive property internally.

Although I can identify the likely source of the issue, I would appreciate any tips for running integration tests after the fix. In particular, I'd like to make sure the fix doesn't cause any unexpected behavior in other scenarios.

[seongahjo]

@Seol-JY
Hi!

Thank you for reporting an issue. It should be handled when min and max are equal.

If this exception is not intended behavior, please let me know if I can submit a PR for the fix!

Sure! We welcome your PR.

[Seol-JY]

@seongahjo

Thank you for welcoming my PR contribution!
While working on this, I've discovered some additional aspects of the issue that I'd like to share:

1. I discovered that this issue extends beyond BigDecimal. I have updated the original issue description to include these additional findings. The same exception occurs with other floating-point types (float, double) when using similar validation constraints. I have added example test cases demonstrating the problem with these other types to make the issue more comprehensive.

2. After investigating further, I believe I've identified the root cause: In JqwikJavaArbitraryResolver, there seems to be an issue with how the inclusive property is handled from the validation annotations.

I've noticed something interesting about the inclusive property behavior. While looking through the code, it seems that:

• When inclusive=false is explicitly set, it's processed correctly
• However, there appear to be cases where inclusive=true (the default value) results in a null value instead of true, causing it to follow the same logic path as false

This observation raises a potential concern:
If the inclusive property isn't being handled consistently in these edge cases, there might be other scenarios where the inclusive/exclusive behavior isn't working as expected. While the current issue manifests when min and max values are equal, the underlying property handling issue could affect validation behavior in other ranges as well.

I'll create a PR to address this issue since I've identified what seems to be causing the incorrect setting of the inclusive field.