-
Notifications
You must be signed in to change notification settings - Fork 3.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GH-42045: [Java] Update Unit Tests for Flight Module #42158
Conversation
- Step 1. update import statements - from `org.junit.Assert` to `org.junit.jupiter.api.Assertions` - Step 2. update annotations - `@After` -> `@AfterEach` - `@AfterClass` -> `@AfterAll` - `@Before` -> `@BeforeEach` - `@BeforeClass` -> `@BeforeAll` - `@Test` -> `@Test` with `org.junit.jupiter`
|
…lightServerTestExtension
…ootAllocatorTestExtension
...ight-sql-jdbc-core/src/test/java/org/apache/arrow/driver/jdbc/FlightServerTestExtension.java
Outdated
Show resolved
Hide resolved
...l-jdbc-core/src/test/java/org/apache/arrow/driver/jdbc/utils/RootAllocatorTestExtension.java
Outdated
Show resolved
Hide resolved
...ache/arrow/driver/jdbc/accessor/impl/calendar/ArrowFlightJdbcIntervalVectorAccessorTest.java
Outdated
Show resolved
Hide resolved
assertAll( | ||
"Errors occurred while fetching data from the ResultSet", | ||
errors.stream() | ||
.map( | ||
error -> | ||
() -> { | ||
throw error; | ||
})); | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ETC. Is this change appropriate?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why would we re-throw the error? I think that would short-circuit the test unexpectedly.
That said, the version of this with an error collector is never actually used. I would rather remove the redundant overloads and let any exceptions here bubble up and terminate the test, instead of try to preserve the original semantics which aren't used anyways.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed it.
Lines 73 to 77 in 323c709
try { | |
columns.add((T) resultSet.getObject(columnName)); | |
} catch (final SQLException e) { | |
throw new RuntimeException(e); | |
} |
Lines 103 to 107 in 323c709
try { | |
columns.add((T) resultSet.getObject(columnIndex)); | |
} catch (final SQLException e) { | |
throw new RuntimeException(e); | |
} |
assertThrows( | ||
SQLException.class, | ||
() -> { | ||
throw new SQLException(); | ||
}); | ||
} else { | ||
assertThat(accessor.getBigDecimal(), is(BigDecimal.valueOf(value))); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ETC. Is this change appropriate?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure this is right...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it should be
if (isInfinite || isNaN) {
assertThrows(SQLException.class, accessor::getBigDecimal);
} else {
assertThat(accessor.getBigDecimal(), is(BigDecimal.valueOf(value));
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed it.
Lines 191 to 195 in 323c709
if (Float.isInfinite(value) || Float.isNaN(value)) { | |
assertThrows(SQLException.class, accessor::getBigDecimal); | |
} else { | |
assertThat(accessor.getBigDecimal(), is(BigDecimal.valueOf(value))); | |
} |
Lines 205 to 211 in 323c709
if (Float.isInfinite(value) || Float.isNaN(value)) { | |
assertThrows(SQLException.class, () -> accessor.getBigDecimal(9)); | |
} else { | |
assertThat( | |
accessor.getBigDecimal(9), | |
is(BigDecimal.valueOf(value).setScale(9, RoundingMode.HALF_UP))); | |
} |
Lines 144 to 148 in 323c709
if (Double.isInfinite(value) || Double.isNaN(value)) { | |
assertThrows(SQLException.class, accessor::getBigDecimal); | |
} else { | |
assertThat(accessor.getBigDecimal(), is(BigDecimal.valueOf(value))); | |
} |
Lines 184 to 190 in 323c709
if (Double.isInfinite(value) || Double.isNaN(value)) { | |
assertThrows(SQLException.class, () -> accessor.getBigDecimal(9)); | |
} else { | |
assertThat( | |
accessor.getBigDecimal(9), | |
is(BigDecimal.valueOf(value).setScale(9, RoundingMode.HALF_UP))); | |
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Point 3. Removing ErrorCollector
.
I removed some methods to remove ErrorCollector
. Is this an appropriate change?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have just completed this PR. Overall, it looks good to me, but there are some points I would like to review.
The PR contains many changes, so I have listed the review points below.
- Point 1. from
TestRule
toExtension
- Point 2.
ParameterizedTest
- Point 3. Removing
ErrorCollector
- ETC.
Thank you always for your review.
@@ -60,7 +62,7 @@ public class TestBasicAuth { | |||
@Test | |||
public void validAuth() { | |||
client.authenticateBasic(USERNAME, PASSWORD); | |||
Assertions.assertTrue(ImmutableList.copyOf(client.listFlights(Criteria.ALL)).size() == 0); | |||
assertTrue(ImmutableList.copyOf(client.listFlights(Criteria.ALL)).size() == 0); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: assertEquals?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed it.
arrow/java/flight/flight-core/src/test/java/org/apache/arrow/flight/auth/TestBasicAuth.java
Line 64 in 323c709
assertEquals(0, ImmutableList.copyOf(client.listFlights(Criteria.ALL)).size()); |
...ight-sql-jdbc-core/src/test/java/org/apache/arrow/driver/jdbc/FlightServerTestExtension.java
Outdated
Show resolved
Hide resolved
...ache/arrow/driver/jdbc/accessor/impl/calendar/ArrowFlightJdbcIntervalVectorAccessorTest.java
Outdated
Show resolved
Hide resolved
assertThrows( | ||
SQLException.class, | ||
() -> { | ||
throw new SQLException(); | ||
}); | ||
} else { | ||
assertThat(accessor.getBigDecimal(), is(BigDecimal.valueOf(value))); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure this is right...
assertThrows( | ||
SQLException.class, | ||
() -> { | ||
throw new SQLException(); | ||
}); | ||
} else { | ||
assertThat(accessor.getBigDecimal(), is(BigDecimal.valueOf(value))); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it should be
if (isInfinite || isNaN) {
assertThrows(SQLException.class, accessor::getBigDecimal);
} else {
assertThat(accessor.getBigDecimal(), is(BigDecimal.valueOf(value));
}
assertAll( | ||
"Errors occurred while fetching data from the ResultSet", | ||
errors.stream() | ||
.map( | ||
error -> | ||
() -> { | ||
throw error; | ||
})); | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why would we re-throw the error? I think that would short-circuit the test unexpectedly.
That said, the version of this with an error collector is never actually used. I would rather remove the redundant overloads and let any exceptions here bubble up and terminate the test, instead of try to preserve the original semantics which aren't used anyways.
@lidavidm I have reflected your review. Thank you for your feedback! |
} | ||
|
||
@Before | ||
public void setup() { | ||
public void setup(Supplier<ValueVector> vectorSupplier) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can't use @BeforeEach
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This logic is similar to initializeDatabase
in the adapter
module. Unfortunately, I haven't found a better way yet. 🥲 If I find a better solution in the future, I'll propose an improvement.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No I think that's fine. Just wanted to make sure. I can recall the discussion we had.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
By the way, should we create an issue to track this in case we get this feature from Junit?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's a good idea. I know which methods need to be updated, so I created an issue for tracking.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks. Let's keep this as a future task, we don't need to update our TODO list as we don't know exactly when we can attempt this.
@MethodSource("data") | ||
public void testShouldGetStringReturnExpectedString(Supplier<ValueVector> vectorSupplier) | ||
throws Exception { | ||
setup(vectorSupplier); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So we have to call this function in each test method?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Based on the information provided by @lidavidm, it will eventually be improved in the future.
It appears junit-team/junit5#878 is the feature request.
collector.checkThat(actualHireDates, is(expectedHireDates)); | ||
collector.checkThat(actualLastSales, is(expectedLastSales)); | ||
|
||
final int finalActualRowCount = actualRowCount; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is this required to be final?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I meant do we need a separate variable?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we don't use final
, we'll see the error: "Variable used in lambda expression should be final or effectively final."
@@ -113,7 +105,7 @@ public void validateShadedJar() throws IOException { | |||
* allowed prefixes | |||
* | |||
* @param name the jar entry name | |||
* @throws AssertionException if the entry is not allowed | |||
* @throws AssertionError if the entry is not allowed |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just curious, how this change comes from? I assume the Jupiter API is using this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The AssertionError
is a built-in class in Java.
The previous code had a typo; it actually used AssertionError
, but the comment described it as AssertionException
. That's why I corrected it.
Lines 117 to 140 in 9f0101e
/** | |
* Check if a jar entry is allowed. | |
* | |
* <p> | |
* A jar entry is allowed if either it is part of the allowed files or it | |
* matches one of the allowed prefixes | |
* | |
* @param name the jar entry name | |
* @throws AssertionException if the entry is not allowed | |
*/ | |
private void checkEntryAllowed(String name) { | |
// Check if there's a matching file entry first | |
if (ALLOWED_FILES.contains(name)) { | |
return; | |
} | |
for (String prefix : ALLOWED_PREFIXES) { | |
if (name.startsWith(prefix)) { | |
return; | |
} | |
} | |
throw new AssertionError("'" + name + "' is not an allowed jar entry"); | |
} |
After merging your PR, Conbench analyzed the 8 benchmarking runs that have been run so far on merge-commit 9d93287. There were no benchmark performance regressions. 🎉 The full Conbench report has more details. It also includes information about 5 possible false positives for unstable benchmarks that are known to sometimes produce them. |
Rationale for this change
Update package from JUnit 4(
org.junit
) to JUnit 5(org.junit.jupiter
).What changes are included in this PR?
org.junit
withorg.junit.jupiter.api
Assertions.assertXXX
toassertXXX
using static importsflight-core
flight-integration-tests
- nothing to changeflight-sql
flight-sql-jdbc-core
ErrorCollection
TestRule
forFlightServerTestExtension
andRootAllocatorExtension
ExpectedException
flight-sql-jdbc-driver
Are these changes tested?
Yes, existing tests have passed.
Are there any user-facing changes?
No.