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

feat(assertions): findXxx() APIs now includes the logical id as part of its result #16454

Merged
merged 9 commits into from
Sep 16, 2021
Merged

feat(assertions): findXxx() APIs now includes the logical id as part of its result #16454

merged 9 commits into from
Sep 16, 2021

Conversation

kaizencc
Copy link
Contributor

@kaizencc kaizencc commented Sep 10, 2021

The current return type of findResources(), findOutputs(), and findMappings() omits the logicalId. This creates ambiguity because it is not trivial to figure out which resource/output/mapping is being matched. For example,

const result = assert.findOutputs('*', {
  Value: 'Fred',
});

Could return a list like:

expect(result).toEqual([
  { Value: 'Fred', Description: 'FooFred' },
  { Value: 'Fred', Description: 'BarFred' },
]);

This does not provide information on which output(s) are being matched to the Value: 'Fred' property. Under the new return type proposed in this PR, the output would look like this:

expect(result).toEqual({
  Foo: { Value: 'Fred', Description: 'FooFred' },
  Bar: { Value: 'Fred', Description: 'BarFred' },
});

Returning the logicalId in this way for all find*() APIs will provide the full picture back to the user.

BREAKING CHANGE: the findResources() API previously returned a list of resources, but now returns a map of logical id to resource.

  • assertions: the findOutputs() API previously returned a list of outputs, but now returns a map of logical id to output.
  • assertions: the findMappings() API previously returned a list of mappings, but now returns a map of logical id to mapping.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

@gitpod-io
Copy link

gitpod-io bot commented Sep 10, 2021

@kaizencc kaizencc changed the title feat(assert): find*() APIs return logicalId feat(assertions): find*() APIs return logicalId Sep 10, 2021
@mergify mergify bot added the contribution/core This is a PR that came from AWS. label Sep 10, 2021
@kaizencc kaizencc requested a review from nija-at September 10, 2021 15:22
Copy link
Contributor

@nija-at nija-at left a comment

Choose a reason for hiding this comment

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

The breaking change entries needs to be fixed -

the findOutputs() API previously returned a list of resources, but now returns a map of logical id to resource

"the findOutputs() API previously returned a list of outputs, but now returns a map of logical id to output"

The other breaking change entry also needs to be fixed.

packages/@aws-cdk/assertions/README.md Outdated Show resolved Hide resolved
packages/@aws-cdk/assertions/lib/private/outputs.ts Outdated Show resolved Hide resolved
packages/@aws-cdk/assertions/test/template.test.ts Outdated Show resolved Hide resolved
packages/@aws-cdk/assertions/test/template.test.ts Outdated Show resolved Hide resolved
@kaizencc kaizencc changed the title feat(assertions): find*() APIs return logicalId feat(assertions): findXxx() APIs return map of logicalId to xxx Sep 14, 2021
@kaizencc kaizencc changed the title feat(assertions): findXxx() APIs return map of logicalId to xxx feat(assertions): findXxx() APIs return map of logicalId to xxx Sep 14, 2021
@kaizencc kaizencc changed the title feat(assertions): findXxx() APIs return map of logicalId to xxx feat(assertions): findXxx() APIs return map of logicalId to xxx Sep 14, 2021
@kaizencc kaizencc requested a review from nija-at September 14, 2021 16:27
@kaizencc
Copy link
Contributor Author

Thanks for the review @nija-at, I'm ready for another pass. Sorry about the continued copy/paste mishaps in the PR description... there should be no more. Build failure has nothing to do with me (I don't think), anything I can do to get it to build correctly?

Copy link
Contributor

@nija-at nija-at left a comment

Choose a reason for hiding this comment

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

Just one comment about return type when no matches.

The rest look good.

@@ -101,7 +101,7 @@ export class Template {
* When a literal is provided, performs a partial match via `Match.objectLike()`.
* Use the `Match` APIs to configure a different behaviour.
*/
public findResources(type: string, props: any = {}): { [key: string]: any }[] {
public findResources(type: string, props: any = {}): { [key: string]: { [key: string]: any } } {
Copy link
Contributor

Choose a reason for hiding this comment

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

oops, I missed this in the last revision. We should be returning undefined here when there are no matches, not an empty object.

That would make the user experience better. Users can do -

const result = template.find...(...);
if (result !== undefined) {
  // do something
}

With what we have today, it'll be

const result = template.find...(...);
if (Object.keys(result).length > 0) {
   // do something
}

WDYT?

Copy link
Contributor Author

@kaizencc kaizencc Sep 15, 2021

Choose a reason for hiding this comment

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

I like this in principle but it will mean that since result can be undefined, something like expect(result.Foo).toEqual({}) becomes expect(result!.Foo).toEqual({}). I could be wrong but forcing users to use the ! escape or otherwise dealing with the possibility of undefined might not make the user experience better.

WDYT, @nija-at? :)

Copy link
Contributor

Choose a reason for hiding this comment

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

Ok, let's go with what you have now. It might actually be the better way.

Comment on lines -270 to +272
expect(Template.fromStack(stack).findResources('AWS::ApiGatewayV2::VpcLink', {
expect(Object.keys(Template.fromStack(stack).findResources('AWS::ApiGatewayV2::VpcLink', {
Name: 'Link-2',
}).length).toEqual(0);
})).length).toEqual(0);
Copy link
Contributor

Choose a reason for hiding this comment

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

This is what I mean.

Would be nicer if we can do -

expect(Template.fromStack(stack).findResources('AWS::ApiGatewayV2::VpcLink', {
  Name: 'Link-2',
})).toBeUndefined();

@nija-at nija-at changed the title feat(assertions): findXxx() APIs return map of logicalId to xxx feat(assertions): findXxx() APIs now includes the logical id as part of its result Sep 16, 2021
@mergify
Copy link
Contributor

mergify bot commented Sep 16, 2021

Thank you for contributing! Your pull request will be updated from master and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).

@aws-cdk-automation
Copy link
Collaborator

AWS CodeBuild CI Report

  • CodeBuild project: AutoBuildProject89A8053A-LhjRyN9kxr8o
  • Commit ID: cbf3d7b
  • Result: SUCCEEDED
  • Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

@mergify mergify bot merged commit 532a72b into aws:master Sep 16, 2021
@mergify
Copy link
Contributor

mergify bot commented Sep 16, 2021

Thank you for contributing! Your pull request will be updated from master and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
contribution/core This is a PR that came from AWS.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants