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

test(NODE-4498): ts tests for OptionalId wrapping schemas with _id #3486

Merged
merged 4 commits into from Dec 15, 2022

Conversation

dariakp
Copy link
Contributor

@dariakp dariakp commented Dec 12, 2022

Description

NODE-4498

What is changing?

Adding tests to make sure document types returned from methods on a collection using an OptionalId-wrapped schema with a defined _id are still assignable to the original schema.

Is there new documentation needed for these changes?

No

What is the motivation for this change?

Ensure user types continue to work as expected when using the OptionalId helper wrapper

Double check the following

  • Ran npm run check:lint script
  • Self-review completed using the steps outlined here
  • PR title follows the correct format: type(NODE-xxxx)[!]: description
    • Example: feat(NODE-1234)!: rewriting everything in coffeescript
  • Changes are covered by tests
  • New TODOs have a related JIRA ticket

@dariakp dariakp changed the title test: better formatting for ts helper tests test(NODE-4498): ts tests for OptionalId wrapping schemas with _id Dec 12, 2022
@dariakp dariakp marked this pull request as ready for review December 12, 2022 21:07
baileympearson
baileympearson previously approved these changes Dec 14, 2022
@@ -44,20 +55,110 @@ class MyId {}
expectNotType<OptionalId<{ _id: MyId; a: number }>>({ a: 3 });
expectNotType<OptionalId<{ _id: MyId; a: number }>>({ _id: new ObjectId(), a: 3 });

// OptionalId assignability when wrapping a schema with _id: ObjectId
Copy link
Contributor

Choose a reason for hiding this comment

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

optional, non-blocking

I've had two thoughts for better "grouping" tests in our typescript tests

  1. we could wrap them in functions (async function testOptionalIdAssignibility() { ... })
  2. we could just wrap them in arbitrary scopes

two benefits of either approach would be better understanding of where each set of tests start and end, as well as no need to worry about naming collisions

thoughts?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It's an interesting idea but I don't want to set the precedent in this PR, we can discuss this further when we revisit cleaning up our TS tests at some point

Comment on lines 68 to 69
const typeTestCollection = new Collection<OptionalId<SchemaWithIdType>>({} as Db, 'test');
const interfaceTestCollection = new Collection<OptionalId<SchemaWithIdInterface>>({} as Db, 'test');
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
const typeTestCollection = new Collection<OptionalId<SchemaWithIdType>>({} as Db, 'test');
const interfaceTestCollection = new Collection<OptionalId<SchemaWithIdInterface>>({} as Db, 'test');
declare const typeTestCollection: Collection<OptionalId<SchemaWithIdType>>;
declare const interfaceTestCollection: Collection<OptionalId<SchemaWithIdInterface>>;

up to you - I find using declare less cluttered than actually instantiating our classes.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Updated

@dariakp dariakp added the Primary Review In Review with primary reviewer, not yet ready for team's eyes label Dec 14, 2022
@baileympearson baileympearson merged commit d56414f into main Dec 15, 2022
@baileympearson baileympearson deleted the NODE-4498/ts-optionalid-assignability-tests branch December 15, 2022 14:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Primary Review In Review with primary reviewer, not yet ready for team's eyes
Projects
None yet
3 participants