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

DRIVERS-555 Unified test format changes for CSOT #959

Merged
merged 14 commits into from
Apr 27, 2022

Conversation

divjotarora
Copy link
Contributor

@divjotarora divjotarora commented Apr 13, 2021

This PR is a rebased and updated version of #873. It only contains Unified Test Format changes and modifications/additions to tests in the valid-pass and invalid directories. The actual CSOT spec tests will be introduced in another PR to avoid making this one larger than necessary.

Notes for reviewers:

  1. This PR bumps the schema version in the unified test format to 1.8 because 1.9
  2. Many of the existing tests for collectionData in the invalid directory weren't functioning as intended because they had an additional foo property in the collection entity declaration. As a result, they were considered invalid because the collection entity was not valid and the initialData field was not being checked. These have been fixed in this PR.
  3. The aforementioned collectionData test files were renamed from collectionData* to initialCollectionData* to reflect a similar change in the test format spec. A new set of outcomeCollectionData* tests have also been added.

Copy link
Member

@jmikola jmikola left a comment

Choose a reason for hiding this comment

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

Don't forget version bump and changlog entries in the spec RST.

@divjotarora divjotarora requested a review from jmikola April 13, 2021 17:04
- name: runCommand
object: *database0
arguments:
commandName: collStats
Copy link
Member

Choose a reason for hiding this comment

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

I know #944 was closed and moved internally for the time being, but heads up to @patrickfreed in case this test will need to be skipped for serverless. IIRC, $collStats isn't supported but I'm not sure about the generic command.

Perhaps there's a more general concern with tests running arbitrary commands that might not be in the versioned API, which will required auditing during the course of that project.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks for the heads up. I made a note to investigate this and skip any of the tests added in this PR or in #960 if they're incompatible with serverless.

Copy link
Member

Choose a reason for hiding this comment

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

Bumping this previously resolved comment.

Unsupported Commands in Serverless Instances doesn't include collStats so I think we're fine here. Just a reminder to run these tests through Atlas Serverless if you get a chance so we double-check before merging. Feel free to resolve after doing so.

Copy link
Member

Choose a reason for hiding this comment

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

In python we don't run the unified test format tests themselves against serverless. Do you think we're supposed to?

Copy link
Member

Choose a reason for hiding this comment

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

Not required by serverless testing, so totally up to you.

I don't think the page I linked above existed when this PR was originally opened, so I just wanted to circle back and cloe the loop on this thread in case anyone comes across it down the line.

@divjotarora divjotarora requested a review from jmikola April 14, 2021 04:54
Copy link

@DmitryLukyanov DmitryLukyanov left a comment

Choose a reason for hiding this comment

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

One question and then LGTM

@divjotarora divjotarora force-pushed the csot-test-format-changes branch from dd50486 to d4aa44e Compare April 30, 2021 00:24
@rozza rozza removed their request for review September 8, 2021 13:52
@benjirewis
Copy link
Contributor

I wonder if we should add a valid-pass test testing the functionality of the new createEntities operation as distinct from the file-level createEntities.

@divjotarora divjotarora requested a review from a team as a code owner April 22, 2022 20:05
@mongodb mongodb deleted a comment from benjirewis Apr 22, 2022
@ShaneHarvey
Copy link
Member

ShaneHarvey commented Apr 22, 2022

I wonder if we should add a valid-pass test testing the functionality of the new createEntities operation as distinct from the file-level createEntities.

Done. I also resolved the merge conflicts and updated the spec version to 1.8. The unified tests are passing in Python.

Copy link
Contributor

@benjirewis benjirewis left a comment

Choose a reason for hiding this comment

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

Question about schema version but otherwise LGTM; new test works in the Go driver and seems to test the correct functionality.

source/unified-test-format/schema-1.8.json Outdated Show resolved Hide resolved
"properties": {
"collectionName": { "type": "string" },
"databaseName": { "type": "string" },
"collectionOptions": { "type": "object" },
Copy link
Member

Choose a reason for hiding this comment

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

Introducing collectionOptions is the only reason you needed to differentiate initialCollectionData from outcomeCollectionData, correct?

To differentiate this from options used when selecting a collection (e.g. collectionOrDatabaseOptions), what do you think about calling this createOptions? I realize the purpose of this field is covered in the spec itself, but I was thinking that may make the test files more self-documenting. I don't feel strongly about this if you'd rather stick with what you have here.

arguments:
entities:
- client:
id: client1
Copy link
Member

Choose a reason for hiding this comment

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

Would it make sense to use YAML anchors/references for entity IDs? I see you did so in some of the other valid-pass tests in this PR. If this gets used as an example for writing actual spec tests it may be prudent to demonstrate the behavior we'd like others to follow.

I don't feel strongly if you'd rather leave this as-is, though.

Copy link
Member

Choose a reason for hiding this comment

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

I wrote this test myself, the other test were written by Divjot ages ago hence the discrepancy. Is there any benefit to using anchors here? They make the file more verbose with no benefit in my opinion.

Copy link
Member

@jmikola jmikola Apr 27, 2022

Choose a reason for hiding this comment

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

Only benefit is if other spec authors happen to use these files as examples down the line, but even then we'd likely catch the lack of anchors in code review. I have no objection to leaving this as-is.

Feel free to resolve after reading.

Copy link
Member

Choose a reason for hiding this comment

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

To be clear, I don't understand what benefit there is to using anchors for entity IDs in any test at all (not just this one).

Copy link
Member

Choose a reason for hiding this comment

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

In the case of entity IDs where the anchor and value are almost always identical, I can see why it seems pointless. I think one small benefit is that a typo is more likely to be caught during JSON conversion instead of a runtime error when executing the tests (due to a failed entity lookup).

For database and collection names, I think the anchors serve a much greater purpose since the values are often very different from the anchor names.

Copy link
Member

Choose a reason for hiding this comment

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

Gotcha. Catching typos does seem like a useful benefit.

source/unified-test-format/unified-test-format.rst Outdated Show resolved Hide resolved
source/unified-test-format/schema-1.8.json Outdated Show resolved Hide resolved
source/unified-test-format/unified-test-format.rst Outdated Show resolved Hide resolved
source/unified-test-format/unified-test-format.rst Outdated Show resolved Hide resolved
Copy link
Member

@ShaneHarvey ShaneHarvey left a comment

Choose a reason for hiding this comment

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

Rebased and updated to schema version 1.9 with the suggested changes.

source/unified-test-format/schema-1.8.json Outdated Show resolved Hide resolved
arguments:
entities:
- client:
id: client1
Copy link
Member

Choose a reason for hiding this comment

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

I wrote this test myself, the other test were written by Divjot ages ago hence the discrepancy. Is there any benefit to using anchors here? They make the file more verbose with no benefit in my opinion.

- name: runCommand
object: *database0
arguments:
commandName: collStats
Copy link
Member

Choose a reason for hiding this comment

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

In python we don't run the unified test format tests themselves against serverless. Do you think we're supposed to?

source/unified-test-format/unified-test-format.rst Outdated Show resolved Hide resolved
source/unified-test-format/unified-test-format.rst Outdated Show resolved Hide resolved
@ShaneHarvey ShaneHarvey requested a review from jmikola April 26, 2022 23:20
@ShaneHarvey ShaneHarvey requested a review from jmikola April 27, 2022 21:15
@ShaneHarvey
Copy link
Member

I resolved the merge conflicts and cleaned up the duplicate initialCollectionData and outcomeCollectionData tests. Ready for another look.

Copy link
Member

@jmikola jmikola left a comment

Choose a reason for hiding this comment

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

LGTM. Optional suggestion to remove some lines from createEntities-operation.yml.

database: *database0
collectionName: &collection0Name coll0

initialData:
Copy link
Member

Choose a reason for hiding this comment

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

Conceivably, you could delete the top-level createEntities and initialData blocks in this test. They don't appear to be used for anything.

Copy link
Member

Choose a reason for hiding this comment

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

Done.

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.

5 participants