-
Notifications
You must be signed in to change notification settings - Fork 2.8k
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
Conversation
Closing (will re-open after fix)The tests are failling. Seems like I didn't commit everything upstream. |
|
||
private static String a2q(String json) { | ||
return json.replace("'", "\""); | ||
} |
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 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.
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.
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 { |
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.
How about unifying the method names?
toJson/fromJson in RemoteZeppelinServerResourceTest vs. deserialization/serialization in HeliumRegistrySerializerTest.
} | ||
|
||
@Test | ||
void fromJson_withLargeDataSet() { |
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.
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.
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.
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
.
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.
@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" + |
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 is there a "1" at the end of the 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.
I figured there could be more?
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.
@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); |
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.
It seems like an action, so wouldn't it be more natural to move it to the "When" section?
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 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(); |
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.
It looks like temporary files are created with each test run. It would be better to add a cleanup step.
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.
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 ?
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.
@JooHyukKim
You're right. But for me, the temporary directory (path: /zeppelin-zengine) hasn't been deleted. Could you check please?
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.
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 |
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 ClusterMessageSerDeserTest uses a HashMap. Are there no issues like 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.
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 { |
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 name SerDeser seems a bit implicit to me. In my opinion, a clearer name, even if longer, would be better, such as ClusterMessageSerializationTest.
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.
Makes sense 👍🏼Will change.
|
||
} | ||
|
||
private File createHeliumPackage(Path testDir, String JSON) throws IOException { |
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 method isn't used. If it's not necessary, how about removing it?
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.
Done!
Thank you @seung-00 for review! |
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. |
What is this PR for?
What type of PR is it?
Improvement
Todos
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?
Screenshots (if appropriate)
Questions: