Skip to content
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

Merged
merged 15 commits into from
Jun 19, 2024

Conversation

llama90
Copy link
Contributor

@llama90 llama90 commented Jun 15, 2024

Rationale for this change

Update package from JUnit 4(org.junit) to JUnit 5(org.junit.jupiter).

What changes are included in this PR?

  • common for all module
    • Step 1. Replacing org.junit with org.junit.jupiter.api
    • Step 2. Updating Assertions.assertXXX to assertXXX using static imports
  • flight-core
    • Updating common
    • Updating annotations
    • Doing self review
  • flight-integration-tests - nothing to change
  • flight-sql
    • Updating common
    • Doing self review
  • flight-sql-jdbc-core
    • Updating common
    • Updating annotations
      • Adding annotations different from before:
        • ErrorCollection
        • TestRule for FlightServerTestExtension and RootAllocatorExtension
        • ExpectedException
    • Doing self review
  • flight-sql-jdbc-driver
    • Updating common
    • Updating annotations
    • Doing self review

Are these changes tested?

Yes, existing tests have passed.

Are there any user-facing changes?

No.

llama90 added 3 commits June 15, 2024 11:27
- 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`
@llama90 llama90 requested a review from lidavidm as a code owner June 15, 2024 13:15
Copy link

⚠️ GitHub issue #42045 has been automatically assigned in GitHub to PR creator.

@github-actions github-actions bot added awaiting committer review Awaiting committer review and removed awaiting review Awaiting review labels Jun 16, 2024
Comment on lines 81 to 89
assertAll(
"Errors occurred while fetching data from the ResultSet",
errors.stream()
.map(
error ->
() -> {
throw error;
}));

Copy link
Contributor Author

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?

Copy link
Member

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed it.

try {
columns.add((T) resultSet.getObject(columnName));
} catch (final SQLException e) {
throw new RuntimeException(e);
}

try {
columns.add((T) resultSet.getObject(columnIndex));
} catch (final SQLException e) {
throw new RuntimeException(e);
}

Comment on lines 192 to 198
assertThrows(
SQLException.class,
() -> {
throw new SQLException();
});
} else {
assertThat(accessor.getBigDecimal(), is(BigDecimal.valueOf(value)));
Copy link
Contributor Author

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?

Copy link
Member

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...

Copy link
Member

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));
}

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed it.

if (Float.isInfinite(value) || Float.isNaN(value)) {
assertThrows(SQLException.class, accessor::getBigDecimal);
} else {
assertThat(accessor.getBigDecimal(), is(BigDecimal.valueOf(value)));
}

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)));
}

if (Double.isInfinite(value) || Double.isNaN(value)) {
assertThrows(SQLException.class, accessor::getBigDecimal);
} else {
assertThat(accessor.getBigDecimal(), is(BigDecimal.valueOf(value)));
}

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)));
}

Copy link
Contributor Author

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?

Copy link
Contributor Author

@llama90 llama90 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@lidavidm @vibhatha

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 to Extension
  • 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);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: assertEquals?

Copy link
Contributor Author

@llama90 llama90 Jun 18, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed it.

assertEquals(0, ImmutableList.copyOf(client.listFlights(Criteria.ALL)).size());

Comment on lines 192 to 198
assertThrows(
SQLException.class,
() -> {
throw new SQLException();
});
} else {
assertThat(accessor.getBigDecimal(), is(BigDecimal.valueOf(value)));
Copy link
Member

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...

Comment on lines 192 to 198
assertThrows(
SQLException.class,
() -> {
throw new SQLException();
});
} else {
assertThat(accessor.getBigDecimal(), is(BigDecimal.valueOf(value)));
Copy link
Member

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));
}

Comment on lines 81 to 89
assertAll(
"Errors occurred while fetching data from the ResultSet",
errors.stream()
.map(
error ->
() -> {
throw error;
}));

Copy link
Member

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.

@github-actions github-actions bot added awaiting changes Awaiting changes and removed awaiting committer review Awaiting committer review labels Jun 17, 2024
@github-actions github-actions bot added awaiting change review Awaiting change review and removed awaiting changes Awaiting changes labels Jun 18, 2024
@llama90
Copy link
Contributor Author

llama90 commented Jun 18, 2024

@lidavidm I have reflected your review. Thank you for your feedback!

}

@Before
public void setup() {
public void setup(Supplier<ValueVector> vectorSupplier) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can't use @BeforeEach?

Copy link
Contributor Author

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.

Copy link
Collaborator

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.

Copy link
Collaborator

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?

Copy link
Contributor Author

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.

Copy link
Collaborator

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);
Copy link
Collaborator

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?

Copy link
Contributor Author

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;
Copy link
Collaborator

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?

Copy link
Collaborator

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?

Copy link
Contributor Author

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."

@github-actions github-actions bot added awaiting merge Awaiting merge and removed awaiting change review Awaiting change review labels Jun 18, 2024
@@ -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
Copy link
Collaborator

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?

Copy link
Contributor Author

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.

/**
* 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");
}

@lidavidm lidavidm merged commit 9d93287 into apache:main Jun 19, 2024
32 checks passed
@lidavidm lidavidm removed the awaiting merge Awaiting merge label Jun 19, 2024
@github-actions github-actions bot added the awaiting committer review Awaiting committer review label Jun 19, 2024
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants