[
https://issues.apache.org/jira/browse/NET-736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Monil Narang updated NET-736:
-----------------------------
Description:
Aim is to improve the test code by avoiding code duplication, improving
maintainability, reducing boilerplate code, and enhancing readability.
{code:java}
@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"));
}
{code}
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. The logic is buried inside repeated assertions, making it harder to see the
variations in test cases.
3. Adding new test cases requires copying and pasting another assertFalse(...)
statement instead of simply adding new data.
4. When a test fails, JUnit only shows which assertion failed, but not which
specific input caused the failure.
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.
was:
Aim is to improve the test code by avoiding code duplication, improving
maintainability, reducing boilerplate code, and enhancing readability.
In the below in SubnetUtilsTest.java:
{code:java}
@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"));
}
{code}
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. The logic is buried inside repeated assertions, making it harder to see the
variations in test cases.
3. Adding new test cases requires copying and pasting another assertFalse(...)
statement instead of simply adding new data.
4. When a test fails, JUnit only shows which assertion failed, but not which
specific input caused the failure.
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.
> Refactored test in SubnetUtilsTest to use parameterized unit testing to
> reduce duplication and improve maintainability
> ----------------------------------------------------------------------------------------------------------------------
>
> Key: NET-736
> URL: https://issues.apache.org/jira/browse/NET-736
> Project: Commons Net
> Issue Type: Improvement
> Affects Versions: 3.11.1
> Reporter: Monil Narang
> Priority: Major
>
> Aim is to improve the test code by avoiding code duplication, improving
> maintainability, reducing boilerplate code, and enhancing readability.
> {code:java}
> @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"));
> }
> {code}
> 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. The logic is buried inside repeated assertions, making it harder to see
> the variations in test cases.
> 3. Adding new test cases requires copying and pasting another
> assertFalse(...) statement instead of simply adding new data.
> 4. When a test fails, JUnit only shows which assertion failed, but not which
> specific input caused the failure.
> 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.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
