(assertions): absentProperty() and not() matchers are incompatible with hasResourceProperties

[nija-at]

Given a template that has a resource with no Properties (just Type)

{
  "Resources": {
    "IamUser1": {
      "Type": "AWS::IAM::User"
    }
  }
}

The following assertion should pass but throws the error Template has 1 resources with type AWS::IAM::User, but none match as expected.

Template.fromStack(stack).hasResourceProperties('AWS::IAM::User', {
  UserName: Match.absentProperty(),
});

Similarly, the assertion -

Template.fromStack(stack).hasResourceProperties('AWS::IAM::User', Match.not({
  UserName: 'MyUser',
}));

The workaround is to do -

Templte.fromStack(stack).hasResource('AWS::IAM::User', {
  Properties: Match.absentProperty(),
});

---

This is 🐛 Bug Report

[kaizencc]

Related: #16653. If that PR is accepted, the workaround for this issue would become:

Template.fromStack(stack).hasResourceProperties('AWS::IAM::User', Match.absentProperty());

With this in mind, is it reasonable to say that hasResourceProperties() assumes that Properties exists on the template? Personally, I see value in fixing this bug as described, but I don't think its life or death.

[nija-at]

#16653. If that PR is accepted, the workaround for this issue would become:

This is not the correct solution for this issue. As stated in the docs, Match.absentProperty() has a specific intent.

Template.fromStack(stack).hasResourceProperties('AWS::IAM::User', {
  UserName: Match.absentProperty(),
});

must automatically pass for both -

"IamUser1": {
  "Type": "AWS::IAM::User"
  "Properties": {}
}

and

"IamUser1": {
  "Type": "AWS::IAM::User"
}

This is because the API is called hasResourceProperties().

[nija-at]

There are a couple of ways to approach this issue -

1. special case hasResourceProperties() such that the template is modified where all Resource blocks for the format "MyLogicalId": { "Type": "AWS::Foo::Bar" } gets converted into "MyLogicalId": { "Type": "AWS::Foo::Bar", "Properties": {} }

2. have a special (private) matcher than handles this case and use that in hasResourceProperties().

[kaizencc]

Reading your comments, I agree that we should do something about this bug :). And I'll look further into the two approaches you've outlined in the second comment. However -

#16653 is not trying to fix this bug. Rather, I think that Match.absentProperty() should be of type Matcher as I imagine that's what the customer expects. My arguments for this change below -

• Would make Matcher.isMatcher(Match.absentProperty()) === true. I believe this to be the sensible result (currently it returns false).
• For: template.hasResourceProperties('Foo::Bar', Match.absentProperty());. I understand that this is confusing so I will do my best. I am arguing that this assertion should return true. It currently does not. The docs say that for Match.absentProperty(), we should "Use this matcher in the place of a field's value, if the field must not be present." I see the second argument in hasResourceProperties() to be the value of the Properties field and thus is a valid place to put Match.absentProperty() (and expect the library to assert that Properties is absent).
• I think it generally Improves code readability by eliminating the special case ABSENT, but that's not as motivating as the above 2 points.

[nija-at]

Ah, my bad! I thought they were related.

[github-actions]

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.