-
Notifications
You must be signed in to change notification settings - Fork 2.4k
test: Add simple integration tests #1797
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
Conversation
…pected" prefix of the basic function result as we already are in the expected directory
… later into a single basic test file, added utils/stack.py
…tion. Updated the makefile to not check coverage for integration tests
…ication tests to their own file, fixed some names
…efile black commands to include the tests_integ directories
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like a great start! Some comments attached
…pected" prefix of the basic function result as we already are in the expected directory
…ces, added simple tests and doc for the table_print utils
… to python2, added a comment in the deployer classes ported over from sam-cli to underline it
Codecov Report
@@ Coverage Diff @@
## develop #1797 +/- ##
===========================================
- Coverage 93.97% 93.84% -0.14%
===========================================
Files 89 89
Lines 5826 5881 +55
Branches 1185 1203 +18
===========================================
+ Hits 5475 5519 +44
- Misses 162 166 +4
- Partials 189 196 +7
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This generally looks good. I have a few small comments about keeping consistent between our repos. The other main things for me is there is a lot of borrowed code from SAM CLI to help deploy these stacks. Which I think is ok but do we need all of it? More code here, means more to maintain. I wonder if it is worth stripping this down to reduce the amount of code needed for our integ tests.
Makefile
Outdated
pytest --cov samtranslator --cov-report term-missing --cov-fail-under 95 tests | ||
pytest --cov samtranslator --cov-report term-missing --cov-fail-under 95 tests/* | ||
|
||
test-integ: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: can we match the naming with SAM CLI? https://github.com/aws/aws-sam-cli/blob/develop/Makefile#L17 That way we are not trying to remember which project does which thing?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated the command name to integ-test.
Makefile
Outdated
pytest --cov samtranslator --cov-report term-missing --cov-fail-under 95 tests/* | ||
|
||
test-integ: | ||
pytest --no-cov tests_integ/* |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same nit here: I would prefer if we standardize our naming and structure across all our repos we own.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just so I understand correctly, does this mean moving the whole content of the current tests
dir under tests/unit
and moving the integration tests under tests/integration
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just moving the tests_integration
content in tests/integration
will make the unit tests also run the integration tests so we may have to move everything.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have rename the integration tests folder to have the same name with samcli. Since the unit tests are directly under tests
and we don't have a unit
folder for them, so currently we keep the integration
folder outside the tests
folder to separate them from the unit tests. If we create a unit
folder for the unit tests in the future, then we can directly move the integration
into tests
to make them consistently with samcli style.
tests_integ/helpers/base_test.py
Outdated
cls.s3_bucket_name = S3_BUCKET_PREFIX + generate_suffix() | ||
cls.session = boto3.session.Session() | ||
cls.my_region = cls.session.region_name | ||
cls.s3_client = boto3.client("s3") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we be creating clients based on the session instead? I think this is typically the better practice, though it probably doesn't impact anything here. Just caught my eye is all.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep this could be better indeed, to be sure we are using the same session throughout
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
By the boto3 documentation: "Boto3 acts as a proxy to the default session. This is created automatically when you create a low-level client." So all the clients are created by using the default session and during the tests we don't use any customized session.
tests_integ/helpers/base_test.py
Outdated
cls.lambda_client = boto3.client("lambda") | ||
cls.iam_client = boto3.client("iam") | ||
cls.api_v2_client = boto3.client("apigatewayv2") | ||
cls.sfn_client = boto3.client("stepfunctions") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we really need each of these clients for every integ test? Shouldn't we only create the client the individual tests need?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was thinking of this as a way to provide a simple toolbox so that every test could access any service easily, we'll check if creating all the client for each test takes too many resources (memory or cpu time)
Note that the session is not thread safe so instantiating all the clients once for the whole test suite may not be a good idea.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could set up getters with lazy initialization.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated with a Client_provider class with lazy initialization.
""" | ||
Empties and deletes the bucket used for the tests | ||
""" | ||
s3 = boto3.resource("s3") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why use resource here but client everywhere else? Seems like resource is a much better way to handle things in boto3 in general?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems resource
is more high level that client
, we'll check to see if we can use resource everywhere.
We needed the resource
here to get the list of files in a paginated way.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
client
is low level and has typically maps 1:1 with the AWS service API while resource
is high level but does not provide 100% API coverage of AWS services. Most of the case we use client
, here we use resource
since it provides a easier way to lists all the objects compared to the client
.
try: | ||
cls.s3_client.delete_object(Key=object_summary.key, Bucket=cls.s3_bucket_name) | ||
except ClientError as e: | ||
LOG.error( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this cause a test to fail? If there is data left around, will that cause issue for the next run of the tests?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure cleanup of a test is part of the test itself, so not sure it should fail.
What we could do is attempt to clean it again and if it fails set this resource name aside and attempt to clean it again at the end of the run.
This shouldn't cause an issue for the next run as we are adding a simple random suffix to each of the objects, stacks and buckets, that we create (see generate_suffix()
). I also added this suffix so that we could run the tests in parallel but for now it's not an option as we get throttled.
if cls.my_region == "us-iso-east-1": | ||
return "https://s3.us-iso-east-1.c2s.ic.gov/{}/{}".format(cls.s3_bucket_name, file_name) | ||
if cls.my_region == "us-isob-east-1": | ||
return "https://s3.us-isob-east-1.sc2s.sgov.gov/{}/{}".format(cls.s3_bucket_name, file_name) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there no way to get this from S3 itself? Seems like a maintenance burden otherwise.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems you can only get a presigned temporary URL from the client.
@@ -0,0 +1,147 @@ | |||
import json |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we have a better name then "helpers"? We should try to be explicit (single principle) and in my experience, these types of classes/files just become dumping grounds
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree, also helpers/helpers.py
is redundant.
We could maybe move the transform_template
function to helpers\template.py
and the rest to helpers\resource.py
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
* set up integration test infrastructure for SAM translator * migrated basic integration tests Co-authored-by: Mathieu Grandis <[email protected]>
Issue #, if available:
Description of changes:
Description of how you validated changes:
Checklist:
make pr
passesExamples?
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.