fix: KeyError: u'AWS_IAM' and add typing

[GavinZZ]

Issue #, if available

Description of changes

Fixing Availability Dip KeyError: u'AWS_IAM'.

Description of how you validated changes

Unit and integration tests passed locally.

Checklist

• Adheres to the development guidelines
• Add/update unit tests using:
  • Correct values
  • Bad/wrong values (None, empty, wrong type, length, etc.)
  • Intrinsic Functions
• Add/update integration tests
• Update documentation
• Verify transformed template deploys and application functions as expected
• Do these changes include any template validations?
  • Did the newly validated properties support intrinsics prior to adding the validations? (If unsure, please review Intrinsic Functions before proceeding).
    • Does the pull request ensure that intrinsics remain functional with the new validations?

Examples?

Please reach out in the comments, if you want to add an example. Examples will be
added to sam init through https://github.com/awslabs/aws-sam-cli-app-templates/

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

[ssenchenko]

Somehow we missed this case in our tests, which led to a runtime error.
Let's add some tests, which can reproduce the situation when the key was missing and make sure it's not gonna happen again. Even unit test with mocking dependencies would be better then nothing

[hoffa]

Any tests to ensure the issue doesn't get introduced again later?

[ssenchenko]

How come these are easier to read? A lot of copy/pasting, if we change anything, need to change in 4 files?

[hoffa]

How come these are easier to read? A lot of copy/pasting, if we change anything, need to change in 4 files?

Transforms should nearly always be deterministic, so no changes to transform outputs.

Edit: neither is the epitome of readability to be fair. There's a few issues with unit tests for transforms, since it only tests small sections of the code. e.g. it could be possible to have a plugin that runs after the transform that breaks the transform, but the unit test would still pass.

[ssenchenko]

How come these are easier to read? A lot of copy/pasting, if we change anything, need to change in 4 files?

Transforms should nearly always be deterministic, so no changes to transform outputs.

Edit: neither is the epitome of readability to be fair. There's a few issues with unit tests for transforms, since it only tests small sections of the code. e.g. it could be possible to have a plugin that runs after the transform that breaks the transform, but the unit test would still pass.

I believe it's possible, but shouldn't it be tested in that plugin then? I'm just worried that we keep adding tests which are flakey...

[hoffa]

How come these are easier to read? A lot of copy/pasting, if we change anything, need to change in 4 files?

Transforms should nearly always be deterministic, so no changes to transform outputs.
Edit: neither is the epitome of readability to be fair. There's a few issues with unit tests for transforms, since it only tests small sections of the code. e.g. it could be possible to have a plugin that runs after the transform that breaks the transform, but the unit test would still pass.

I believe it's possible, but shouldn't it be tested in that plugin then? I'm just worried that we keep adding tests which are flakey...

These are not integration tests, they're never flaky. They run the full transform code locally and compare the outputs.

[ssenchenko]

gration tests, they're never flaky. They run the full transform code locally and

gotcha, my bad :)

[GavinZZ]

Transform tests are not flaky. It's simply comparing the output against the expected json files.

I do agree with Chris that unit tests are highly couple to implementation details, so if a small implementation detail changes we need to spend effort fixing them.