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

[HUDI-568] Improve unit test coverage #1473

Merged
merged 1 commit into from
Apr 9, 2020
Merged

Conversation

ramachandranms
Copy link
Contributor

What is the purpose of the pull request

Improve code coverage for the following classes

  • HoodieTableMetaClient
  • RocksDBDAO
  • HoodieRealtimeFileSplit

Brief change log

Added new tests for functions missing coverage

Verify this pull request

Added tests in the following files

  • TestRocksDBManager.java
  • TesthoodieTableMetaClient.java
  • TestHoodieRealtimeFileSplit.java

Committer checklist

  • Has a corresponding JIRA in PR title & commit

  • Commit message is descriptive of the change

  • CI is green

  • Necessary doc changes done or have another open PR

  • For large changes, please consider breaking it into sub-tasks under an umbrella JIRA.

@codecov-io
Copy link

codecov-io commented Apr 1, 2020

Codecov Report

Merging #1473 into master will increase coverage by 0.40%.
The diff coverage is n/a.

Impacted file tree graph

@@             Coverage Diff              @@
##             master    #1473      +/-   ##
============================================
+ Coverage     67.64%   68.05%   +0.40%     
  Complexity      261      261              
============================================
  Files           348      348              
  Lines         16672    16670       -2     
  Branches       1694     1694              
============================================
+ Hits          11278    11344      +66     
+ Misses         4653     4586      -67     
+ Partials        741      740       -1     
Impacted Files Coverage Δ Complexity Δ
...apache/hudi/common/util/collection/RocksDBDAO.java 74.86% <ø> (+17.40%) 0.00 <0.00> (ø)
...pache/hudi/common/table/HoodieTableMetaClient.java 83.76% <0.00%> (+7.14%) 0.00% <0.00%> (ø%)
.../hudi/hadoop/realtime/HoodieRealtimeFileSplit.java 100.00% <0.00%> (+73.52%) 0.00% <0.00%> (ø%)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 78b3194...5d45687. Read the comment docs.

@@ -75,9 +75,6 @@ public RocksDBDAO(String basePath, String rocksDBBasePath) {
* Create RocksDB if not initialized.
*/
private RocksDB getRocksDB() {
if (null == rocksDB) {
Copy link
Contributor

Choose a reason for hiding this comment

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

What if getRocksDB is called repetitively ? It should not init() every time, do we plan to add a different check in init to allow for better code coverage ?

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 looked at the entire code. it seems like init() gets called from the only constructor in this class. so there will never be a case where rocksDB == null. this code seemed redundant and was never going to get called. that's why removed it. without this code, we are just going to return the rocksDB instance everytime without checking. Also checked the code and there is no where the variable is being set to null

Copy link
Contributor

Choose a reason for hiding this comment

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

sounds good, thanks for the explanation

Copy link
Contributor Author

Choose a reason for hiding this comment

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

refactored the code as you requested. lmk if this can be merged. thanks

@@ -99,25 +104,119 @@ public void testRocksDBManager() {
List<Pair<String, Payload>> gotPayloads =
dbManager.<Payload>prefixSearch(family, prefix).collect(Collectors.toList());
Integer expCount = countsMap.get(family).get(prefix);
System.out.printf("%s,%s: %d, %d\n", prefix, family, expCount == null ? 0L : expCount.longValue(), gotPayloads.size());
Copy link
Contributor

@n3nash n3nash Apr 1, 2020

Choose a reason for hiding this comment

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

can we make this log ? if there is already an assert, this might not be needed

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 was just a debug statement. so removed it

}

@Test
public void write() 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.

Can you add comments for each of the tests you have added to explain what you are trying to test here ? Especially with the mock, it is unclear to a new reader

Copy link
Contributor Author

Choose a reason for hiding this comment

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

added comments

public class TestHoodieRealtimeFileSplit {

private HoodieRealtimeFileSplit split;
private String basePath = "/tmp";
Copy link
Contributor

@n3nash n3nash Apr 1, 2020

Choose a reason for hiding this comment

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

Take a look at https://github.com/apache/incubator-hudi/blob/master/hudi-common/src/test/java/org/apache/hudi/common/HoodieCommonTestHarness.java#L48 to better initialize things like basePath and other variables that you intend to use throughout the execution of the test

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 a pure unit test and everything that happens is within the context of this class. all the variables used here are just dummy paths. since i am doing checks on the length of data written down the call stack, it will be hard to validate things if we use temporary folder names given by the testing framework.

Copy link
Contributor

Choose a reason for hiding this comment

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

The path is something you can keep in a temporary variable in a @BeforeClass or @before, it's best to use that or if you prefer use the TemporaryFolder from junit -> would like to avoid hard-coded temp paths used for testing

Copy link
Contributor

@n3nash n3nash left a comment

Choose a reason for hiding this comment

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

Left some comments, rest LGTM @ramachandranms

Copy link
Contributor

@n3nash n3nash left a comment

Choose a reason for hiding this comment

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

@ramachandranms left 1 comment

Classes improved:
* HoodieTableMetaClient
* RocksDBDAO
* HoodieRealtimeFileSplit
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.

None yet

3 participants