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

[ZEPPELIN-6033] Add tests for de/serialization #4790

Closed
wants to merge 9 commits into from

Conversation

JooHyukKim
Copy link
Contributor

What is this PR for?

What type of PR is it?

Improvement

Todos

  • - Write tests

What is the Jira issue?

JIRA-ISSUE

This PR adds test coverage to existing classes that are part of de/serialization.
Note that this PR is pure in sense that Gson vs Jackson is not covered here, but only data processing part.

How should this be tested?

  • Strongly recommended: add automated unit tests for any new or changed behavior
  • Outline any manual steps to test the PR here.

Screenshots (if appropriate)

Questions:

  • Does the license files need to update?
  • Is there breaking changes for older versions?
  • Does this needs documentation?

@JooHyukKim
Copy link
Contributor Author

Closing (will re-open after fix)

The tests are failling. Seems like I didn't commit everything upstream.

@JooHyukKim JooHyukKim closed this Aug 13, 2024
@JooHyukKim JooHyukKim reopened this Aug 19, 2024

private static String a2q(String json) {
return json.replace("'", "\"");
}
Copy link
Contributor

Choose a reason for hiding this comment

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

Is a2q really necessary? If not, I think using a pure JSON format without a2q could make the test clearer. Keeping the test focused on the target, which in this case is JSON serialization/deserialization, could help keep the test simple.
Also, in this PR HeliumRegistrySerializerTest does not use a2q.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sure I will remove a2q methods.
I disagree with you and a2q methods don't hinder us from focusing on the SUT.
I just don't have much preference over a2q here.

"}";

@Test
void testDeserialization() throws IOException {
Copy link
Contributor

Choose a reason for hiding this comment

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

How about unifying the method names?
toJson/fromJson in RemoteZeppelinServerResourceTest vs. deserialization/serialization in HeliumRegistrySerializerTest.

}

@Test
void fromJson_withLargeDataSet() {
Copy link
Contributor

Choose a reason for hiding this comment

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

It seems like a performance test. In my opinion, it's better to avoid performance testing in unit tests. I think unit tests and performance tests have different purposes.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Oh my bad. I think the test name made you get the wrong idea 😅.
The test is intended to test (sort of) long data as input.
There is a whole lot of Zeppelin integration tests that run wayyyy over a minute 😆
This test won't even leave a dent on the performance of Zeppelin test suite.

I changed the name from LargeDataSet to LongDataset.

Copy link
Contributor

Choose a reason for hiding this comment

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

@JooHyukKim
Does using long data actually change the functionality here? If it's just a unit test, the toJson test in this class already seems to cover the same function.


class HeliumRegistrySerializerTest {

private String HELIUM_PACKAGE_JSON_1 = "{\n" +
Copy link
Contributor

Choose a reason for hiding this comment

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

Why is there a "1" at the end of the 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.

I figured there could be more?

Copy link
Contributor

Choose a reason for hiding this comment

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

@JooHyukKim
If the '1' doesn't have a specific meaning, how about removing it?

assertNotNull(registry.getAll());
assertEquals(1, registry.getAll().size());

HeliumPackage heliumPackage = registry.getAll().stream().findFirst().orElseThrow(RuntimeException::new);
Copy link
Contributor

Choose a reason for hiding this comment

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

It seems like an action, so wouldn't it be more natural to move it to the "When" section?

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 is not an action at all, just another value assertion following...

assertEquals(1, registry.getAll().size());

But I do think it could be simplified.

// When
// Define the output file
Path dir = Files.createDirectory(Paths.get("./" + UUID.randomUUID().toString()));
File newFile = Files.createTempFile(dir, UUID.randomUUID().toString(), ".json").toFile();
Copy link
Contributor

Choose a reason for hiding this comment

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

It looks like temporary files are created with each test run. It would be better to add a cleanup step.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Clean up is already implemented.
There is a delete- hook at line 56.
What I think we need is moving the delete-hook line up to right below this line.
WDYT, @seung-00 ?

Copy link
Contributor

@seung-00 seung-00 Aug 23, 2024

Choose a reason for hiding this comment

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

@JooHyukKim
You're right. But for me, the temporary directory (path: /zeppelin-zengine) hasn't been deleted. Could you check please?

Copy link
Contributor Author

@JooHyukKim JooHyukKim Aug 23, 2024

Choose a reason for hiding this comment

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

Strange, I added delete-on-exit hook on the directory too, just in case.

String key, String value,
String key2, String value2
) {
// TreeMap to ensure serialization order
Copy link
Contributor

@seung-00 seung-00 Aug 19, 2024

Choose a reason for hiding this comment

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

The ClusterMessageSerDeserTest uses a HashMap. Are there no issues like this?

Copy link
Contributor Author

@JooHyukKim JooHyukKim Aug 23, 2024

Choose a reason for hiding this comment

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

Hmmmm🤔 , I don't think so.
Or do you have anything in mind?
TreeMap is actually used to make test results deterministic.


import static org.junit.jupiter.api.Assertions.*;

class ClusterMessageSerDeserTest {
Copy link
Contributor

@seung-00 seung-00 Aug 19, 2024

Choose a reason for hiding this comment

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

The name SerDeser seems a bit implicit to me. In my opinion, a clearer name, even if longer, would be better, such as ClusterMessageSerializationTest.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Makes sense 👍🏼Will change.


}

private File createHeliumPackage(Path testDir, String JSON) throws IOException {
Copy link
Contributor

Choose a reason for hiding this comment

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

This method isn't used. If it's not necessary, how about removing it?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done!

@JooHyukKim
Copy link
Contributor Author

Thank you @seung-00 for review!

@JooHyukKim
Copy link
Contributor Author

JooHyukKim commented Oct 20, 2024

Closing due to inactivity and to give room for other contributions.

It feels like unifying de/serialization library won't be done efficiently with everything (other works) going on right now.

@JooHyukKim JooHyukKim closed this Oct 20, 2024
@JooHyukKim JooHyukKim deleted the ZEPPELIN-6033 branch October 20, 2024 13:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants