-
Notifications
You must be signed in to change notification settings - Fork 9.2k
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
tests/ec2/ami: Rename tests #17849
tests/ec2/ami: Rename tests #17849
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -12,7 +12,7 @@ import ( | |
"github.com/hashicorp/terraform-plugin-sdk/v2/terraform" | ||
) | ||
|
||
func TestAccAWSAMICopy_basic(t *testing.T) { | ||
func TestAccEC2AMICopy_basic(t *testing.T) { | ||
var image ec2.Image | ||
rName := acctest.RandomWithPrefix("tf-acc-test") | ||
resourceName := "aws_ami_copy.test" | ||
|
@@ -39,7 +39,7 @@ func TestAccAWSAMICopy_basic(t *testing.T) { | |
}) | ||
} | ||
|
||
func TestAccAWSAMICopy_Description(t *testing.T) { | ||
func TestAccEC2AMICopy_description(t *testing.T) { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The current guidance for writing acceptance tests uses lowercase for "meta" tests like There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. While Go conventions do allow for capitalized words after the underscore, they apply to types and methods on types. Drawing the analogy to what we're doing, it would be reasonable to apply the same logic. However, I do not think we should have capitalized words after underscores for one simple reason: a badly followed convention is worse than no convention at all. Currently, the capitalized word after an underscore is as likely to tell you nothing about the test as something. As a result, a clear, followable convention would be better. I vote for updating the documentation. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Can you please expand on this? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Currently, there are around about 1256 TestAccAWSAPIGatewayUsagePlan_description()
TestAccAWSAPIGatewayMethod_customrequestvalidator()
TestAccAWSAPIGatewayIntegration_integrationType()
TestAccAWSEBSSnapshot_tags()
TestAccAWSEBSVolume_updateSize()
TestAccAWSEIP_instance()
TestAccAWSGlueTrigger_actions_notify()
TestAccAWSInstance_outpost() There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We should enforce whatever standard we choose. In this case, I think we should pick a standard that improves understandability/readability first, and then update whatever documentation and Semgrep rules to enforce it |
||
var image ec2.Image | ||
rName := acctest.RandomWithPrefix("tf-acc-test") | ||
resourceName := "aws_ami_copy.test" | ||
|
@@ -67,7 +67,7 @@ func TestAccAWSAMICopy_Description(t *testing.T) { | |
}) | ||
} | ||
|
||
func TestAccAWSAMICopy_EnaSupport(t *testing.T) { | ||
func TestAccEC2AMICopy_enaSupport(t *testing.T) { | ||
var image ec2.Image | ||
rName := acctest.RandomWithPrefix("tf-acc-test") | ||
resourceName := "aws_ami_copy.test" | ||
|
@@ -88,7 +88,7 @@ func TestAccAWSAMICopy_EnaSupport(t *testing.T) { | |
}) | ||
} | ||
|
||
func TestAccAWSAMICopy_tags(t *testing.T) { | ||
func TestAccEC2AMICopy_tags(t *testing.T) { | ||
var ami ec2.Image | ||
resourceName := "aws_ami_copy.test" | ||
rName := acctest.RandomWithPrefix("tf-acc-test") | ||
|
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.
What determines whether test naming should include a fully capitalized initialism? Should we enforce the standard?
I've personally leaned towards only capital first letters in test naming after the resource type underscores, even for initialisms, e.g.
TestAccEc2AmiIdsDataSource_basic
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.
Unlike above, the Go convention is clear on this point:
Although the AWS SDK for Go breaks this rule a lot, I have seen efforts to change course and some of the newer APIs follow this rule occassionally. My vote is that we stick with convention and win the respect of Go
codersnaming-convention followers.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.
If we are going to enforce this, we will need to manually enumerate all initialisms and maintain the list going forward. For example, what does
sesv2
convert into?I would prefer to see a proposal on that before really going down this route since it affects all code and testing contributions, otherwise it will be easy to escape out of the desired convention. I'm guessing it would need to be a text file with a list or a Go file with a slice of strings, but we will need to figure out how to ensure it is usable by tooling that needs it and ensure that all contributors know how to add to it and when that is necessary.
For what it is worth, not using initialisms allows you to easily convert snake_case to PascalCase and lowercase to Titlecase without additional logic to also bake in the conversions. Not saying that needs to be an end-all goal, but I'm not sure if folks are really chasing after this project's code for "correctness" in this sense. More likely folks are probably interested in functionality that has readable code and works.
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 specifically limiting the scope of changes to test names. We have non-breaking freedom with test names. However, fixing things in test names but not code introduces a level of inconsistency. For instance, removing "AWS" and "Aws" from test names but not all the resource names. Despite this issue, which I think is small, I love the idea of having one area where we have clean, Go convention adhereing names.
Following Go's conventions, the "V" would either be the next word and capitalized or an initial and capitalized ("Greengrass" is the way it is because AWS treats it as one word):
func TestAccAPIGatewayV2GreatTest_basic
func TestAccCloudHSMV2GreatTest_basic
func TestAccELBV2GreatTest_basic
func TestAccGreengrassV2GreatTest_basic
func TestAccKinesisAnalyticsV2GreatTest_basic
func TestAccLexModelsV2GreatTest_basic
func TestAccLexRuntimeV2GreatTest_basic
func TestAccSESV2GreatTest_basic
func TestAccWAFV2GreatTest_basic
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 like the
<service>V2
approach in general. However, it doesn't look right after initialisms, such asWAFV2
. For straight up consistency, I'd go with<service>V2
. For ease of readability or aesthetics, I'd go with<full word service>V2
and<initialism service>v2
.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 can extract the list of initialisms from the SDK packages at
service/<service package>/service.go
files. The constantServiceID
could be checked for all-caps. There are some special cases, such asACM PCA
, where there's a space.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 also somewhat relates to another cleanup issue I'd like to open around standardizing service and resource naming in, e.g. error messages