-
-
Notifications
You must be signed in to change notification settings - Fork 32
Component testing guide #733
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
Co-authored-by: Dan Miller <miller0daniel@gmail.com> Co-authored-by: RoseSecurity <72598486+RoseSecurity@users.noreply.github.com>
Co-authored-by: RoseSecurity <72598486+RoseSecurity@users.noreply.github.com>
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.
When I see a component named like step-1 and then step-2, it seems like we are advocating a naming convention. Is this the naming convention we use?
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.
no. this is files that reference examples for specific step number in Write test section
| @@ -0,0 +1,812 @@ | |||
| --- | |||
| title: Components Testing | |||
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.
| title: Components Testing | |
| title: Component Testing |
| @@ -0,0 +1,812 @@ | |||
| --- | |||
| title: Components Testing | |||
| sidebar_label: Components Testing | |||
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.
| sidebar_label: Components Testing | |
| sidebar_label: Component Testing |
| --- | ||
| title: Components Testing | ||
| sidebar_label: Components Testing | ||
| description: 'Our components testing strategy and resources' |
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.
| description: 'Our components testing strategy and resources' | |
| description: 'Our guide for implementing automated component testing with Terratest' |
| </Step> | ||
|
|
||
| <Step> | ||
| ### <StepNumber/> Install Go Lang |
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.
| ### <StepNumber/> Install Go Lang | |
| ### <StepNumber/> Install Golang |
| Build a Geodesic infrastructure container. This container that has all the tools like terraform and atmos for building infrastructure. It's built from the `Dockerfile` and there are some predefined targets defined in the `Makefile` to make this easy. Customize these for your organization. Here are examples of both for reference. | ||
|
|
||
| <CollapsibleText type="medium"> | ||
| <CodeBlock title="Dockerfile">{PartialDockerfile}</CodeBlock> |
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 are we deleting this?
| Import the dependent component for `default-test` stack | ||
| <CodeBlock language="yaml" title="test/fixtures/stacks/orgs/default/test/tests.yaml">{Step3Stack}</CodeBlock> | ||
|
|
||
| Add the dependent component to test suite with go code |
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.
| Add the dependent component to test suite with go code | |
| Add the dependent component to test suite with Go code |
|
|
||
| Add the dependent component to test suite with go code | ||
| By default, the test suite will add a unique random value to the `attributes` terraform variable. | ||
| This is to avoid resoureces naming collision with other tests that are using the same component. |
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 is to avoid resoureces naming collision with other tests that are using the same component. | |
| This is to avoid resource naming collisions with other tests that are using the same component. |
| By default, the test suite will add a unique random value to the `attributes` terraform variable. | ||
| This is to avoid resoureces naming collision with other tests that are using the same component. | ||
| But in some cases, you may need to pass unique value to specific input for the component. | ||
| Check advanced example of the most common use case - dns delegated domain 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.
| Check advanced example of the most common use case - dns delegated domain name. | |
| Check out the advanced example for the most common use-case with the `dns-delegated` domain name. |
|
|
||
| Component testing framework assumes that each component's repo structure follows the convention when all component terraform source code | ||
| would be stored in `src` directory and everything related to tests will be placed in `test` directory. | ||
| Tests consists of two coupled parts - atmos configuration fixtures and tests written on go code. |
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.
| Tests consists of two coupled parts - atmos configuration fixtures and tests written on go code. | |
| Tests consists of two coupled parts - atmos configuration fixtures and tests written on Go code. |
what
why