[DRIVERS-2414] CSFLE spec tests should not specify options under an "opts" operation argument Created: 15/Aug/22  Updated: 18/Aug/22  Resolved: 18/Aug/22

Status: Closed
Project: Drivers
Component/s: Client Side Encryption
Fix Version/s: None

Type: Spec Change Priority: Unknown
Reporter: Jeremy Mikola Assignee: Unassigned
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to DRIVERS-2017 Add ClientEncryption entity and Key M... Closed
Driver Changes: Needed

 Description   

Summary

Quoting Expressing Required and Optional Parameters in the unified test format spec:

Some specifications group optional parameters for API methods under an options parameter (e.g. options: Optional<UpdateOptions> in the CRUD spec); however, driver APIs vary in how they accept options (e.g. Python's keyword/named arguments, session as either an option or required parameter depending on whether a language supports method overloading). Therefore, test files SHALL declare all required and optional parameters for an API method directly within operation.arguments (e.g. upsert for updateOne is not nested under an options key).

The CSFLE spec tests do not follow this. For example, createDataKey.yml includes an opts key within the operation's arguments object.

This was likely an oversight in DRIVERS-2017.

Motivation

Is this issue urgent?

No.

Is this ticket required by a downstream team?

No.

Is this ticket only for tests?

Yes.



 Comments   
Comment by Kevin Albertson [ 18/Aug/22 ]

Good point. I missed that during review too.

Closing as "Won't Fix" since it does not interfere with driver testing, and would require some effort to update the tests and test runners.

Comment by Jeremy Mikola [ 15/Aug/22 ]

Feel free to resolve/close if there is no intention to address this, but I felt compelled to point it out when I encountered this. It was definitely missed during the original review for DRIVERS-2017.

Generated at Thu Feb 08 08:25:31 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.