-
Notifications
You must be signed in to change notification settings - Fork 245
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
DRIVERS-555 Unified test format changes for CSOT #959
Conversation
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.
Don't forget version bump and changlog entries in the spec RST.
source/unified-test-format/tests/invalid/expectedError-isTimeoutError-type.yml
Outdated
Show resolved
Hide resolved
source/unified-test-format/tests/invalid/initialCollectionData-additionalProperties.yml
Outdated
Show resolved
Hide resolved
source/unified-test-format/tests/invalid/initialCollectionData-collectionName-required.yml
Outdated
Show resolved
Hide resolved
source/unified-test-format/tests/invalid/initialCollectionData-collectionName-type.yml
Outdated
Show resolved
Hide resolved
source/unified-test-format/tests/valid-pass/matches-lte-operator.yml
Outdated
Show resolved
Hide resolved
source/unified-test-format/tests/valid-pass/initialCollectionData-collectionOptions.yml
Outdated
Show resolved
Hide resolved
- name: runCommand | ||
object: *database0 | ||
arguments: | ||
commandName: collStats |
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 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.
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.
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.
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.
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.
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.
In python we don't run the unified test format tests themselves against serverless. Do you think we're supposed to?
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.
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.
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.
One question and then LGTM
dd50486
to
d4aa44e
Compare
I wonder if we should add a |
source/unified-test-format/tests/valid-pass/initialCollectionData-collectionOptions.yml
Outdated
Show resolved
Hide resolved
Done. I also resolved the merge conflicts and updated the spec version to 1.8. The unified tests are passing in Python. |
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.
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/tests/valid-pass/createEntities-operation.yml
Outdated
Show resolved
Hide resolved
"properties": { | ||
"collectionName": { "type": "string" }, | ||
"databaseName": { "type": "string" }, | ||
"collectionOptions": { "type": "object" }, |
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.
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.
source/unified-test-format/tests/invalid/collectionOrDatabaseOptions-timeoutMS-type.yml
Outdated
Show resolved
Hide resolved
source/unified-test-format/tests/valid-pass/createEntities-operation.yml
Outdated
Show resolved
Hide resolved
arguments: | ||
entities: | ||
- client: | ||
id: client1 |
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.
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.
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 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.
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.
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.
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.
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).
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.
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.
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.
Gotcha. Catching typos does seem like a useful benefit.
source/unified-test-format/tests/valid-pass/matches-lte-operator.yml
Outdated
Show resolved
Hide resolved
…ke timeoutMS an integer, other fixes
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.
Rebased and updated to schema version 1.9 with the suggested changes.
source/unified-test-format/tests/invalid/collectionOrDatabaseOptions-timeoutMS-type.yml
Outdated
Show resolved
Hide resolved
source/unified-test-format/tests/valid-pass/createEntities-operation.yml
Outdated
Show resolved
Hide resolved
arguments: | ||
entities: | ||
- client: | ||
id: client1 |
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 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.
source/unified-test-format/tests/valid-pass/entity-cursor-iterateOnce.yml
Outdated
Show resolved
Hide resolved
- name: runCommand | ||
object: *database0 | ||
arguments: | ||
commandName: collStats |
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.
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/tests/valid-pass/matches-lte-operator.yml
Outdated
Show resolved
Hide resolved
I resolved the merge conflicts and cleaned up the duplicate initialCollectionData and outcomeCollectionData tests. Ready for another look. |
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.
LGTM. Optional suggestion to remove some lines from createEntities-operation.yml
.
database: *database0 | ||
collectionName: &collection0Name coll0 | ||
|
||
initialData: |
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.
Conceivably, you could delete the top-level createEntities
and initialData
blocks in this test. They don't appear to be used for anything.
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.
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
andinvalid
directories. The actual CSOT spec tests will be introduced in another PR to avoid making this one larger than necessary.Notes for reviewers:
collectionData
in theinvalid
directory weren't functioning as intended because they had an additionalfoo
property in the collection entity declaration. As a result, they were considered invalid because the collection entity was not valid and theinitialData
field was not being checked. These have been fixed in this PR.The aforementionedcollectionData
test files were renamed fromcollectionData*
toinitialCollectionData*
to reflect a similar change in the test format spec. A new set ofoutcomeCollectionData*
tests have also been added.