[NET-736] Refactored testNET641 to use parameterized unit testing

[Monilnarang]

Referencing NET-736
Aim:
Improve the test code by avoiding code duplication, improving maintainability, and enhancing readability. By converting the test into a parameterized unit test, we reduce boilerplate code, make it easier to extend by simply adding new input values, and improve debugging by clearly identifying which test case fails instead of searching through individual assertions.

@Test
    public void testNET641() {
        assertFalse(new SubnetUtils("192.168.1.0/00").getInfo().isInRange("0.0.0.0"));
        assertFalse(new SubnetUtils("192.168.1.0/30").getInfo().isInRange("0.0.0.0"));
        assertFalse(new SubnetUtils("192.168.1.0/31").getInfo().isInRange("0.0.0.0"));
        assertFalse(new SubnetUtils("192.168.1.0/32").getInfo().isInRange("0.0.0.0"));
    }

In the above in SubnetUtilsTest.java:

1. The same method call new SubnetUtils(...).getInfo().isInRange(...) is repeated multiple times with different inputs, making the test harder to maintain and extend.
2. When a test fails, JUnit only shows which assertion failed, but not which specific input caused the failure.
3. Adding new test cases requires copying and pasting another assertFalse(...) statement instead of simply adding new data.

To accomplish this, I have retrofitted the test into a parameterized unit test. This reduces duplication, allows easy extension by simply adding new value sets, and makes debugging easier as it clearly indicates which test failed instead of requiring a search through individual assertions.

[garydgregory]

I'm not a fan of a PR for a one-off style changes to a single method. It feels like change for the sake of change. We don't use CsvSource at all ATM. I'm not opposed to using it but if used, it should be done consistently in the whole class, maybe the whole package, maybe in the whole component. It's a discussion worth having. What do others think? The topic is really about parameterized tests, not CsvSource specifically. In this example, it just so happens that the relevant types are all String, so it's a simple mapping for CsvSource without worrying about any conversion issues.

[Monilnarang]

Thank you for your prompt and thoughtful feedback, @garydgregory. I really appreciate it. I’m open to extending these changes across this class and others for consistency. I started with a small PR to make the review process smoother and to facilitate discussion before making broader changes. Happy to adapt based on the team’s direction.

[Monilnarang]

Thanks, @garydgregory, for pointing out the type conversion issues with CsvSource—I wasn’t aware of that. Since this test class already uses FieldSource, I’ve incorporated it into my changes. Could you please take another look?