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

Add couple of sanity checks, improve e2e test usability and fix minor bugs #43

Merged
merged 7 commits into from
Aug 27, 2021

Conversation

pradh
Copy link
Contributor

@pradh pradh commented Aug 27, 2021

New checks:

  1. Existence checks for unit and mmethod of SVObs
  2. Ensure DCID refs have a valid set of characters in a backward-compatible way.
  3. Expect refs for units
  4. Ensures name / dcid match in Prop/Class

(Some of the above should also address #36, though existence-checks would already report errors, in a round-about way.)

While rolling this out, found it very hard to update the expectation for the e2e tests, so made two changes:

  1. Instead of asserting on the first error in map diff, print all relevant info and then assert.
  2. Add a mode to these tests where we can actually generate the expectation. (The counter maps aren't really ordered in json, but that might be okay for now.)

Fix a couple of bugs in parser:

  1. When StringUtil.SplitStructuredLineWithEscapes returns failure, we shouldn't throw exception. (See added McfParserTest unit tests)
  2. Allow merging empty graphs into an empty McfGraph. This is useful for testing empty files.

@@ -55,34 +55,34 @@ typeOf: dcid:City
Node: dcid:CH-SH
dcid: "CH-SH"
name: "Shanghai"
location:
location:
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Just noticing... filed #44 for this

TestUtil.readStringFromPath(expectedReportPath),
TestUtil.readStringFromPath(actualReportPath));
assertEquals(
org.datacommons.util.TestUtil.mcfFromFile(expectedGeneratedFilePath.toString()),
Copy link

Choose a reason for hiding this comment

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

is just using TestUtil sufficient (rather than the full package path?)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

There's a TestUtil in this directory too.

actualLog.getCounterSet().getCountersMap());
assertMapsAreEqual(
"Level Summary", expectedLog.getLevelSummaryMap(), actualLog.getLevelSummaryMap());
assertTrue(actualLog.getEntriesList().containsAll(expectedLog.getEntriesList()));
Copy link

Choose a reason for hiding this comment

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

have you tried this pattern? it might give better error messages (there's also an option to ignore ordering).

assertThat(actualRecordProtos)
    .displayingDiffsPairedBy(Record::getId)
    .containsExactlyElementsIn(expectedRecords);

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 is an awesome tip! Though I didn't use this specifically, I finally found a way to do "expect" and got rid of the custom function.

Copy link
Contributor

@chejennifer chejennifer left a comment

Choose a reason for hiding this comment

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

thanks for the changes!

@@ -33,15 +33,24 @@
// directory, add an input directory and an output directory. In the input directory, put the test
// files you want to run the lint tool against. In the output directory, put a report.json file with
// the expected report output.
//
// These tests can be run in a mode to produce golden files, as below:
// mvn -DgoldenFilesPrefix=$PWD/tool/src/test/resources/org/datacommons/tool test
Copy link
Contributor

Choose a reason for hiding this comment

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

should there be a space like "mvn -D goldenFilesPrefix..."?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@@ -38,6 +40,14 @@
Set.of(Vocabulary.DOMAIN_INCLUDES, Vocabulary.RANGE_INCLUDES);
private final Set<String> PROP_REFS_IN_PROP =
Set.of(Vocabulary.NAME, Vocabulary.LABEL, Vocabulary.DCID, Vocabulary.SUB_PROPERTY_OF);

// Includes: a-z A-Z 0-9 _ & + - % / . )(
Copy link
Contributor

Choose a reason for hiding this comment

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

do we want to allow "&" in dcid? When I did an import, I noticed that enums that represent a combination of multiple enums uses "&" to concat the multiple enums and so having "&" in a dcid gave me problems.

Copy link

Choose a reason for hiding this comment

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

i believe we already include "&", but i was hoping we can avoid any special url characters from our dcid's (so no [&?= #]%+). we do use / but are able to handle this on the clients

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Unfortunately, &+% show up currently in our refs/dcids today.

I've filed #45 to track this. Perhaps we could disallow in import tool with a special mode to run backward-compatibly, or something?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

since this is long-pending/important, lets switch discussion to #45, and I'll submit this PR :)

Copy link
Contributor Author

@pradh pradh left a comment

Choose a reason for hiding this comment

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

Thanks for the review!

TestUtil.readStringFromPath(expectedReportPath),
TestUtil.readStringFromPath(actualReportPath));
assertEquals(
org.datacommons.util.TestUtil.mcfFromFile(expectedGeneratedFilePath.toString()),
Copy link
Contributor Author

Choose a reason for hiding this comment

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

There's a TestUtil in this directory too.

@@ -33,15 +33,24 @@
// directory, add an input directory and an output directory. In the input directory, put the test
// files you want to run the lint tool against. In the output directory, put a report.json file with
// the expected report output.
//
// These tests can be run in a mode to produce golden files, as below:
// mvn -DgoldenFilesPrefix=$PWD/tool/src/test/resources/org/datacommons/tool 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.

actualLog.getCounterSet().getCountersMap());
assertMapsAreEqual(
"Level Summary", expectedLog.getLevelSummaryMap(), actualLog.getLevelSummaryMap());
assertTrue(actualLog.getEntriesList().containsAll(expectedLog.getEntriesList()));
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 is an awesome tip! Though I didn't use this specifically, I finally found a way to do "expect" and got rid of the custom function.

@@ -38,6 +40,14 @@
Set.of(Vocabulary.DOMAIN_INCLUDES, Vocabulary.RANGE_INCLUDES);
private final Set<String> PROP_REFS_IN_PROP =
Set.of(Vocabulary.NAME, Vocabulary.LABEL, Vocabulary.DCID, Vocabulary.SUB_PROPERTY_OF);

// Includes: a-z A-Z 0-9 _ & + - % / . )(
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Unfortunately, &+% show up currently in our refs/dcids today.

I've filed #45 to track this. Perhaps we could disallow in import tool with a special mode to run backward-compatibly, or something?

@pradh pradh merged commit 6199f84 into datacommonsorg:master Aug 27, 2021
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.

3 participants