Merge test guides into a single task-based guide#8307
Conversation
|
Hi there, I'm the Modular magician. I've detected the following information about your changes: Diff reportYour PR hasn't generated any diffs, but I'll let you know if a future commit does. |
Tests analyticsTotal tests: Action takenFound 2 affected test(s) by replaying old test recordings. Starting RECORDING based on the most recent commit. Click here to see the affected testsTestAccContainerAwsNodePool_BetaBasicHandWritten|TestAccComputeFirewallPolicyRule_multipleRules |
|
|
melinath
left a comment
There was a problem hiding this comment.
Overall this is a big improvement even though it doesn't cover everything in the ticket - leaving it at the current scope sounds good. I have some comments / questions / change requests below.
| {{< /tab >}} | ||
| {{< /tabs >}} | ||
|
|
||
| ## Add an update test |
There was a problem hiding this comment.
As written, I find the procedures in this a little hard to scan; I'm not entirely sure how to fix it. I wonder if this might be a case where some additional context about the flow of the test would be useful?
Part of what makes it hard to scan is that there are a number of * placeholders here which mean different things from each other, which seems potentially confusing - see https://developers.google.com/style/placeholders for recommendations on how to use placeholders (not all of which apply but most of which are useful!)
There was a problem hiding this comment.
I might have to circle back to this comment after going through the other items. Could you clarify what you mean by scanning, I'm not sure I understand the use case?
There was a problem hiding this comment.
by "scan" I just mean "look at and be able to quickly identify / understand important pieces of information (for example because they are formatted consistently)"
There was a problem hiding this comment.
Hmm ok, I think that makes sense. It sounds like you are finding the * to be inconsistent with the other documentation, and would prefer a placeholder instead? A placeholder gets really weird in these types of instructions, and I'm not fully seeing how it improves on the scan-ability you mentioned, but I can try it out if you think that would fix the issue.
There was a problem hiding this comment.
coming back to this - I think I was thinking something like resource_PRODUCT_RESOURCE_generated_test.go. But I think I would also be fine with considering this non-blocking and coming back to it later if it's an issue.
There was a problem hiding this comment.
I've taken another pass at this, and think it has turned out better, but curious your thoughts.
Instead of having so many editing instructions in a row without providing a concrete starting or ending place, I added examples of the result. I think this helps give the reader a model of what is being changed (two main blocks of code), and breaks it up visually. It can probably still be tweaked, and we may even be able to trim down the instructions further because the reader has an example to compare to.
Regarding the placeholders, we can still fit them in here, but I did come across a piece that I found weird, which is capitalization. If we used placeholders, I would expect something like resource_PRODUCT_RESOURCE_generated_test.go and then further down testAccCheckPRODUCT_RESOURCEDestroyProducer, and besides the format looking weird, PRODUCT_RESOURCE is not the exact same value in both cases. Can you think of a good way to handle this?
There was a problem hiding this comment.
I think the examples are a good improvement and address a lot of my concerns. regarding the placeholders I was thinking you could do something like testAccCheckProductResourceDestroyProducer to match the camelCase but the examples might already sufficiently explain that part.
There was a problem hiding this comment.
Ok, sounds good. FWIW I think that is a reasonable solution for the destroy producer, ideally if we can get the ProductResource part to clearly stand out, but I would be slightly worried about a reader thinking they need to delete a function with that exact name.
I will leave it with the asterisks for now as "good enough", but not opposed to future improvements.
af4ce5c to
8e6cf1f
Compare
|
Hi there, I'm the Modular magician. I've detected the following information about your changes: Diff reportYour PR hasn't generated any diffs, but I'll let you know if a future commit does. |
1 similar comment
|
Hi there, I'm the Modular magician. I've detected the following information about your changes: Diff reportYour PR hasn't generated any diffs, but I'll let you know if a future commit does. |
Tests analyticsTotal tests: Action takenFound 1 affected test(s) by replaying old test recordings. Starting RECORDING based on the most recent commit. Click here to see the affected testsTestAccContainerAwsNodePool_BetaBasicHandWritten |
|
|
22c6e39 to
222f23a
Compare
|
Hi there, I'm the Modular magician. I've detected the following information about your changes: Diff reportYour PR hasn't generated any diffs, but I'll let you know if a future commit does. |
| {{< /tab >}} | ||
| {{< /tabs >}} | ||
|
|
||
| ## Add an update test |
There was a problem hiding this comment.
I think the examples are a good improvement and address a lot of my concerns. regarding the placeholders I was thinking you could do something like testAccCheckProductResourceDestroyProducer to match the camelCase but the examples might already sufficiently explain that part.
| subnetwork_name: "example-subnet" | ||
| network_name: "example-network" | ||
| ``` | ||
| {{< hint warning >}} |
There was a problem hiding this comment.
Yea, it's something that only happens inside the "tab", and I wasn't able to trick it into placing the text where I wanted. I'll just un-indent for now.
Tests analyticsTotal tests:
|
|
Hi there, I'm the Modular magician. I've detected the following information about your changes: Diff reportYour PR hasn't generated any diffs, but I'll let you know if a future commit does. |
| - If beta-only fields are being tested, do the following: | ||
| - Change the file suffix to `.go.erb`. | ||
| - Add `<% autogen_exception -%>` to the top of the file. | ||
| - Wrap the beta-only tests in a version guard: `<% unless version = 'ga' -%>...<% else -%>...<% end -%>`. |
There was a problem hiding this comment.
| - Wrap the beta-only tests in a version guard: `<% unless version = 'ga' -%>...<% else -%>...<% end -%>`. | |
| - Wrap the beta-only tests in a version guard: `<% unless version == 'ga' -%>...<% else -%>...<% end -%>`. |
| - If beta-only fields are being tested, do the following: | ||
| - Change the file suffix to `.go.erb`. | ||
| - Add `<% autogen_exception -%>` to the top of the file. | ||
| - Wrap the beta-only tests in a version guard: `<% unless version = 'ga' -%>...<% else -%>...<% end -%>`. |
There was a problem hiding this comment.
| - Wrap the beta-only tests in a version guard: `<% unless version = 'ga' -%>...<% else -%>...<% end -%>`. | |
| - Wrap the beta-only tests in a version guard: `<% unless version == 'ga' -%>...<% else -%>...<% end -%>`. |
| ``` | ||
| <% autogen_exception -%> | ||
| ``` | ||
| - If any of the added Go code (including any imports) is beta-only, change the file suffix to `.go.erb` and wrap the beta-only code in a version guard: `<% unless version = 'ga' -%>...<% else -%>...<% end -%>`. |
There was a problem hiding this comment.
| - If any of the added Go code (including any imports) is beta-only, change the file suffix to `.go.erb` and wrap the beta-only code in a version guard: `<% unless version = 'ga' -%>...<% else -%>...<% end -%>`. | |
| - If any of the added Go code (including any imports) is beta-only, change the file suffix to `.go.erb` and wrap the beta-only code in a version guard: `<% unless version == 'ga' -%>...<% else -%>...<% end -%>`. |
|
@melinath Nice catch on those! |
|
Hi there, I'm the Modular magician. I've detected the following information about your changes: Diff reportYour PR hasn't generated any diffs, but I'll let you know if a future commit does. |
Tests analyticsTotal tests:
|
…#8307) * Merge test guides into a single task-based guide * Tweak test docs after initial review * Fix ref and replace use of standard tests * Update intructions for update tests to be more clear * Update resource doc to mention renaming needed for tests * Unindent warning * Fix version guards

Subset of b/261212591
Fixes hashicorp/terraform-provider-google#12792
Fixes hashicorp/terraform-provider-google#12424
This change is similar to #8193, where we are making an effort to consolidate our guides into a low number of task-based guides.
The new guide walks the user through creating all necessary tests for a resource ("basic", "full", and "update"). There are tabs for MMv1 resources vs handwritten resources. The previous guides have been deleted, and any reference material will be consolidated into separate pages.
If this PR is for Terraform, I acknowledge that I have:
make testandmake lintin the generated providers to ensure it passes unit and linter tests.Release Note Template for Downstream PRs (will be copied)